devopsy.kinsta.cloud

Tag: developer portal

Smoothing API Onboarding With Simulation and Documentation
“Soon we’ll be making another run…And love, exciting and new, Come aboard, we’re expecting you…”– Theme from The Love Boat, American television program, circa 1977

If software is eating the world, then APIs are eating software. Investment in the API economy is increasing. More than 200 million APIs are already out there in the world, and more than 24,000 are publicly available as of 2022, and surely these figures have only skyrocketed since then.

APIs were supposed to ease the journey of creating innovative new features and services within internal and external-facing applications, while making integration smooth sailing.

Unfortunately, leveraging API services within your own application development process often feels less like stepping onto the welcoming deck of The Love Boat, and more like getting marooned on an island for the next season of Survivor.

Developers want to build functionality that delivers the maximum business value—with a minimum of effort—so don’t leave them stranded when they are trying to consume APIs.

Barriers to API Onboarding

The process of adding some API calls to an application seems quite simple in comparison to the old days of web services and integration buses. A provider publishes an API with a Open API spec, and developers connect to it. Unfortunately, onboarding seldom works out that simply for several reasons:
- Poor documentation. While there may be a Swagger or Postman file sitting there for reference, chances are the documentation isn’t updated as often as the API, nor does it provide helpful instructions or code samples that help developers structure their own calls.
- Inconsistently available sandboxes. All too often, there isn’t a reliable way to try out the API, thereby wasting developer’s time and impacting quality. Further, sandboxes are hosted in temporary instances or unscalable architecture that can lag or go down at any time. Complex test scenarios like load testing or negative testing may be disallowed or rate-limited, and teams may have scheduling conflicts over a limited number of sandbox environments.
- Poor maintenance. Test API environments are often poorly maintained, and further, API producers don’t usually update test instances or inform developers about changes and downtime until after the events have already passed.
- Downstream dependencies. Any published API may have known or unknown downstream connections to other data services and API that can change or interfere with business logic or availability.
Simulating Success With API Mocking

Developers need a great onboarding experience to successfully make that first successful call, and then they need support on a continuous basis as they productively incorporate APIs into their app.

DevOps methodologies recommend automation at every stage of the continuous delivery pipeline, with “shift left” early testing and validation of all components that will make up the finished application. That’s certainly helpful, but for API development in particular, a lack of ready sandboxes leaves developers doing the cumbersome work of prototyping test APIs for early consumption, when they would rather spend their time developing and testing features.

The practice of API mocking allows developers to simulate the stateful behavior of a responsive live API service, even if the producer of that service hasn’t yet provided a live version or test environment.

The WireMock Cloud solution provides an on-demand environment with sophisticated API mocking that can be generated from specifications, Swagger definitions or even from live service traffic. The resulting mock API instances are addressable just like live production APIs, but because they are hosted in a stable multi-tenant cloud environment, they often prove to be ‘better than the real thing’ in terms of availability, performance, and predictability.

In essence, a mock API automatically represents a solid reference documentation, with an accompanying OpenAPI spec of the producer’s target API. It also makes every API consumed by developers more modular, because teams can consume and share the mock API assets and specs when collaborating on contract tests and reproducing results.

Where to start? Just create mocks and embed them in your developer portal, so every API also has a matching prebuilt mock. With this packaging, API mocks can be used as a smart, reliable sandbox which will improve the onboarding developer experience for APIs in your developer portal.

The Intellyx Take

Who wants to build more APIs, and maintain additional sandbox infrastructure, just to test APIs?

The most valuable resource of any developer is time, so don’t give them a frustrating reason to jump ship before they’ve even onboarded. API mocking simulates production APIs and provides useful documentation, in a ready-to-consume environment developers will love.

API mocking allows teams to work in parallel, eliminating constraints and returning time to every turn of every development cycle. It’s all smooth sailing from here!

©2024 Intellyx B.V. Intellyx is editorially responsible for this document. No AI bots were used to write this content. Image source: Adobe Express AI. At the time of writing, WireMock is an Intellyx customer.
April 2, 2024
Survey Surfaces Significant Platform Engineering Gains

A survey of 100 software engineers working at organizations in the U.S. and Western Europe published today found nearly all (99%) have embraced platform engineering to some degree as a methodology to manage DevOps workflows at scale, with more than half (53%) having done so in the last year.

Conducted by Port, a provider of a proprietary internal developer portal (IDP) platform, the survey also found 83% of respondents have also incorporated GitOps workflows into their platform engineering practices.

The survey also found 85% are working for organizations that have either started deploying IDPs or plan to do so in the coming year. However, what constitutes an IDP is not exactly clear, with more than a third (35%) that have implemented one reporting they are relying on spreadsheets to manage their IDP. A little over half (53%) of respondents, in contrast, are using an IDP to provide developers with self-service capabilities for setting up environments to write code that either was custom built, is based on open source Backstage software originally developed by Spotify or a commercial IDP platform.

Among the 85% of respondents using or planning to use an IDP, the main measure of success is to improve developer productivity (56%), followed by reduced time to deployment (25%). Despite those initiatives, only slightly more than a third (34%) said IDPs are helping DevOps teams enforce software engineering standards.

Roni Floman, chief marketing officer for Port, said overall, the survey suggests developers are wasting a lot of time on tasks that have little to do with writing code. For example, the survey finds that prior to embracing platform engineering, developers spent three to four hours a day on non-core activities, resulting in weeks being required to eventually deploy software in a production environment.

The biggest challenge organizations face when embracing platform engineering is convincing developers that a centralized team has their best interests at heart. Many application development teams embraced DevOps as a best practice in the first place to escape the tyranny of a centralized IT team. The issue is that, as a result, many of them now find themselves managing tasks that have little to do with writing code. Platform engineering seeks to strike a balance between giving developers the ability to adopt new tools when they see fit and the benefits of having a dedicated platform engineering team that automates processes on their behalf.

Unless platform engineering teams find a way to get developers to buy into the effort, however, it’s unlikely they will succeed, noted Floman.

Each organization will need to determine for itself what level of platform engineering makes sense for them to implement, given their unique culture. In most cases, a platform engineering initiative will start small before increasing in size and scope as momentum is gained. In the meantime, the most important thing any platform engineering team clearly needs to do in the short term is engage developers. After all, the best way to get support for any change to a DevOps workflow is, as always, to convince developers it was their idea in the first place.

December 13, 2023
Atlassian Makes Compass IDP Generally Available

Atlassian this week made generally available a Compass developer experience platform through which DevOps teams can employ a software-as-a-service (SaaS) platform to centralize the management of the environments used to create code.

Taylor Pechacek, head of product for Compass at Atlassian, said Compass provides an instance of an internal developer platform (IDP) that is simpler for DevOps teams to set up and maintain.

At its core, Compass provides access to a software component catalog to track, search and discover the component and approved infrastructure that can be used to build and deploy applications.

In addition, templates enable developers to self-service environment setup using a set of policies that provide guardrails to ensure developers follow best practices for provisioning cloud resources and setting up pipelines.

Finally, Atlassian is making available scorecards based on the DevOps Research and Assessment (DORA) metrics defined by Google.

Compass is designed to be integrated with a wide range of continuous integration/continuous delivery (CI/CD) platforms and third-party observability, testing, collaboration and source code management tools, said Pechacek. The goal is to minimize context switching as much as possible for developers accessing the Compass platform, he added.

That approach also provides a level of consistency that both fosters collaboration and makes it simpler to onboard new members to a development team, noted Pechacek.

While IDPs as a concept have been around for some time, they are now central to any effort to embrace platform engineering methodologies to implement best DevOps practices at scale. The issue platform engineering teams need to come to terms with is determining whether they want to build and maintain an IDP versus invoking one provided as a SaaS application.

Regardless of approach, platform engineering teams are trying to strike a delicate balance between centralizing the management of development environments and the ability of developers to innovate by adding new tools to their development environment. Organizations clearly want developers to become more productive by spending less time managing development environments, but many of those same developers tend to jealously guard their prerogatives when it comes to the tools they prefer.

The challenge, of course, is that spending less time managing a development environment doesn’t necessarily mean more code will be written. All it does is afford developers the opportunity to write more code. The issue is that the writing of quality code only really occurs when developers are inspired, but at the very least, configuring a development environment shouldn’t stand in the way of creativity.

It’s not clear how many organizations are embracing platform engineering methodologies, but it’s apparent that more supervision is being brought to how applications are built and deployed within the context of a set of DevOps best practices. The challenge and the opportunity now is to make sure developers buy into, rather than resist, those efforts.

October 18, 2023
Internal Developer Portal: What it Is and Why You Need One

One main advantage of the cloud is that it offers developers flexibility and a self-service solution. Instead of having to contact the central infrastructure team whenever a dev team needs a new server or a cluster, the dev team can do it themselves through a simple web UI. This change drastically improves productivity. But there’s a caveat: Most companies don’t actually want to use the default portals provided by cloud providers. There are a few reasons for this: Security, simplicity or the need for custom, company-specific options, to name a few. That’s why we now see a move toward internal developer portals. In this post, you’ll learn what internal developer portals are and how they can make your developers’ lives easier.

What is an Internal Developer Portal?

An internal developer portal is a self-service application and data store that lets developers and managers track and organize everything their engineering teams build and operate.

Imagine that you need to create a new microservice. Your developers will first need to provision infrastructure for it; for that, they’ll use a cloud provider portal. Next, they’ll need to create new CI/CD pipelines or modify existing ones. Then, they’ll probably need to implement some changes to existing components like the API gateway and database. Lastly, they’ll probably need to add some documentation or make their new microservice visible to the rest of the company.

Overall, they’ll need to touch a few different UIs or portals. Now, imagine they can do all of that from one place. That’s what we call an internal developer portal. It’s a self-service portal that lets developers catalog and understand relationships, ownership, resources, external service data and anything else they need to understand and operate their software.

Why Does an Internal Developer Portal Matter?

Now that we know what an internal developer portal is, let’s take a step back and discuss why internal developer platforms (IDPs) are on the rise. The main reason is because of the increased complexity of both software and infrastructure. Especially when we’re talking about cloud-based microservices environments, it’s challenging even for senior engineers to keep track of all dependencies and things that must happen every time changes are needed. Microservices architectures are heavily decentralized. Although you’ll still see the typical three-tier software architecture, in most cases, it’s no longer easy to tell by looking at a random component where it fits in the bigger picture just by its name or server location.

Natural Evolution

The second reason is that it’s simply a natural next step in the evolutionary process for self-service portals. Old-school, on-premises-based environments barely had any self-service capabilities. Do you remember how difficult that was? To request a new server, you had to email the central infrastructure team. If you were lucky, you’d get what you needed in a matter of hours or days. But more often than not, it took a week or two. And if you made some mistake in the initial request, that would cost you an extra week (or more) of waiting. More advanced companies? Even when they created some custom self-service solutions, these were limited. Often, it wasn’t much more than an online form to be processed by the infrastructure team which often became a bottleneck for all dev teams.

When most companies started moving to the cloud, they began to see the benefits of self-service platforms. The ability to create servers ad hoc within a matter of minutes led to increased developer productivity, faster time-to-market and better quality software. But again, cloud-provider platforms are suitable for managing cloud infrastructure; you need more than that for a complete solution. Your developers can be more effective at creating and changing cloud infrastructure, but everything else was still done separately. And that’s how we naturally evolved into the demand for internal developer portals. To bring even more flexibility and clarity while increasing your dev teams’ productivity, you need to take the next step in the self-service platform evolution and combine all the things developers need into one internal developer portal.

Clarity

Also, from a business perspective, internal developer portals bring clarity and offer a good overview of all your infrastructure and software development efforts. Even if you’re in the cloud and your dev teams can manage the infrastructure as they choose, you still need some control and oversight—for example, to avoid wasting money on test servers that developers forgot to delete. Sure, you can get simple reporting from your standard cloud-provider portal, but what if you’re using multiple cloud providers or have a hybrid-cloud environment? An internal developer portal can benefit both developers and their managers. Long story short: IDP portals are the future of software development.

What Can an IDP Actually Do?

How do you create an IDP for your company? You can build your own from scratch, use some OSS offerings or go for ready-to-use products.

Build Your Own

The first option would give you the most flexibility and ability to perfectly tailor the solution to your needs and the needs of your developers. However, building your own IDP from scratch is almost like building your own operating system from scratch. It requires a lot of work which could negate the main benefits that IDP is supposed to bring. You want to implement IDP to increase developer productivity and decrease time-to-market, but it would take you months to build it and years to maintain it to keep it working properly with constantly changing cloud APIs.

Open Source IDP

The next option is open source IDPs. Since IDPs are, in general, quite complicated pieces of software, there aren’t many options to choose from. The two most popular are Backstage and Gimlet. Backstage is more of a DIY platform for building developer portals, which means you’ll still need to spend quite a lot of time creating something that actually benefits your company. Gimlet is quite popular, too, but it focuses on Kubernetes-based environments. Both are great tools—don’t get me wrong—but if you’re looking for something ready to use and feature-rich, consider the third option.

Ready-to-Use Solutions

The last option is to use a ready-to-use product. Ready-to-use solutions combine the IDP functionality with incident response capabilities as well as metrics, dependencies visualization and filtering across multiple clouds.

Internal developer portals are gaining popularity for good reason. In fact, many companies have been trying to build IDPs for years without even knowing the solution had a name. This is because an IDP-like solution will naturally evolve in any company that cares about developer experience and moving faster. The problem is that it usually takes years to come up with a single solution that fulfills all their needs. Another problem is that most of these organically created internal developer portals focus only on the tech side and skip the business needs. That’s why a purpose-built tool can be much easier and faster to implement while also doing its job much better.

May 5, 2022