Podcasts about developer portal

Audio version of video on YouTube. Announcing the launch of the enhanced App validation tool in Developer Portal! Public preview of SharePoint Framework 1.20 – First release of upcoming features Dev Tools for Microsoft Teams tabs Guidelines to create or upgrade Copilot extensions

In this episode we're joined by Adam Rogal, who leads Developer Productivity and Platform at DoorDash. Adam describes DoorDash's journey with their internal developer portal, and gives advice for  other teams looking to follow a similar path. Adam also describes how his team delivered value quickly and drove adoption for their developer platform.Discussion points:(1:47) Why DoorDash explored implementing a developer portal(6:59) The initial vision for the developer portal 12:19 Funding ongoing development 16:01 Deciding what to include in the portal 19:15 Coming up with a name for the portal 20:01 Advice for interested beginners23:55 Putting together a business case32:32 Getting adoption for the portal 37:27 Driving initial awareness 41:29 Getting feedback from developers48:33 What Adam would have done differentlyMentions and links:Adam Rogal on LinkedInGet started (API)New testing and monitoring tools

What's up folks, today we're joined by Ryan Gunn, Director of Demand Gen & Marketing Ops at Aptitude 8.Summary: HubSpot is not just a user-friendly CRM but also a forward-looking tool in the rapidly evolving world of AI and martech. While it's not a substitute for a dedicated data warehouse for complex queries, it serves well as a real-time connector to other systems via CRM cards. Gaining practical skills from HubSpot's developer portal is critical—certifications alone won't cut it. If keeping up with martech changes overwhelms your in-house team, specialized consultancies offer a reservoir of constantly updated expertise. Sound documentation serves as the bedrock of your internal processes, setting you up for long-term success. Don't just read about it; listen to the podcast episode for deep, actionable insights into leveraging HubSpot for AI integration and data quality.About Ryan Ryan started his career by getting his feet wet freelancing in design and social media projects He took on the role of Inbound Marketing Account Exec at Boyle public affairs where he got to wear a bunch of different marketing hats, including his first taste of Hubspot He later became Senior Digital Marketing Manager at WealthForge, a fintech company where he owned marketing automation and lead gen Ryan the took on the challenge of Head of Marketing at Array, an event technology startup where he built their marketing department from the ground up in two years Today, Ryan works at Aptitude 8, an Elite HubSpot partner consultancy where he started in a client facing consulting role helping clients with big hairy migration projects like migrating Marketo and Pardot into Hubspot and marketing attribution projects Today he's Aptitude 8's Director of Demand Gen and MOPs responsible for growing the consultancy's services business and brand awareness HubSpot's Emerging AI Landscape and Market AdoptionWe started by asking Ryan about his experience with HubSpot's new AI tools and their current usage in the market, he offered a comprehensive view. HubSpot is rolling out two significant tools: Content Assistant and ChatSpot. Content Assistant serves as an internal ChatGPT, letting users draft blog posts or emails directly within HubSpot's interface. ChatSpot, while more complex, operates as an external system linked to your CRM data, generating reports through natural language prompts.However, these tools are still in the nascent stage. Ryan revealed that the implementation rate is relatively low at this point. Despite the curiosity among clients to explore these features, the tools haven't fully integrated into business processes yet. But don't let that deter you; HubSpot is ahead of the curve in the AI game. According to Ryan, HubSpot has already laid out a roadmap for AI-based tools that will extend far beyond just Content Assistant and ChatSpot. We're talking about reporting assistants, automation assistants, and even an AI-powered website builder.This isn't a mere extension of existing features; it's a reimagination of what a CRM can be. HubSpot is not stopping at providing the basic CRM tools; they're layering AI functionalities on top, touching every aspect of their platform. While current adoption may be slow, Ryan sees this as an indicator of an inevitable, transformative change in how businesses will interact with CRMs.Key Takeaway: The adoption rate of HubSpot's new AI tools may be in its infancy, but that's more a function of market readiness than a comment on the tools' potential. With an expansive AI roadmap, HubSpot is setting the stage for a future where AI isn't just an add-on; it's intrinsic to the CRM experience. It's worth keeping an eye on HubSpot's next moves, as they'll likely set the pace for the industry.The AI Integration Dilemma for Emerging Tech FoundersWhen Ryan was asked about the hesitation some tech founders have regarding AI integration into their products, his stance was unequivocal: it's early days, but progress is rapid. A mere six months ago, AI was barely a blip on most of our work radars. Now, it's becoming integral. Founders find themselves at a crossroads, forced to make a pivotal decision. Either integrate AI into their software or offer the option to connect their software with AI tools via third-party platforms like Zapier.But this isn't a decision to make lightly. According to Ryan, it boils down to whether the company aims to be a comprehensive platform or a specialized point solution. Opting for the latter means the pressure is on to excel in that niche. If they don't, larger platforms like HubSpot are poised to scoop up those features, layer AI functionalities over them, and package it as a part of their already established CRM systems. These integrated solutions may not be better, but they offer convenience by residing in an ecosystem clients are already invested in.So what's the crux of the issue? To integrate or not isn't just a technical decision; it's a strategic one that could define a company's future. Choose to stay specialized, and you need to be the best in that realm to stay relevant. Integrate AI, and you may not outshine the giants, but you become a part of a broader, rapidly evolving landscape.Key Takeaway: Hesitation to integrate AI into your product could lead to missed opportunities. You're choosing between being a specialist in a niche or part of a wider, faster-evolving tech ecosystem. Each has its merits, but understand this: indecision is a decision in itself, and the pace of AI development waits for no one.The Vital Role of Data Structure in AI AdoptionWhen Ryan was asked about the practicalities of implementing AI tools in CRM systems like HubSpot, he was quick to pinpoint the critical role of data structure. It's simple: your AI experience is only as good as the data you provide. If you've got a shaky foundation, don't expect the sophisticated algorithms to correct your mistakes. AI isn't a magic wand that turns bad data into insightful outcomes; it's a magnifier that accentuates the quality—or lack thereof—of your existing information.This isn't a new phenomenon. Ryan compares the situation to current reporting structures within organizations. How many times have you heard, "I don't trust this report" or "These numbers aren't right"? Often, the blame doesn't lie with the reporting tool but with the underlying data or its flawed structuring. Just like you wouldn't blame a mirror for how you look in the morning, pointing fingers at AI for poor results steers the attention away from the actual culprit: bad data.This brings us to an important realization: if you're going to integrate AI into your processes, you need to take the time to audit, clean, and structurally organize your data. AI isn't forgiving; it doesn't make bad data better, it makes it obvious. And in the realm of business where data-driven decisions are pivotal, shoddy data is not just an inconvenience—it's a handicap.Key Takeaway: Before even thinking about adopting AI into your CRM or any business process, ensure your data is clean and well-structured. Anything less and you're setting yourself up for failure. AI amplifies the quality of your data; it doesn't fix it. Make this your first step in any AI implementation journey.The Tug-of-War Between All-In-One Solutions and Niche ExpertiseWhen asked about the consolidation of martech tools, particularly in platforms like HubSpot, Ryan offered a clear-cut viewpoint. The future belongs to either all-encompassing platforms or specialized point solutions catering to niche markets. There's a thinning middle ground, and if you're neither a giant like HubSpot nor focused on a niche, you'll likely be pushed out of the marketplace.Ryan also shed light on the growing demand for industry-specific expertise. Clients are turning away from large agencies that claim to be jacks-of-all-trades but masters of none. They want agencies that excel in distinct verticals or use-cases. It's a trend that's not limited to service companies; tech providers face the same reality. HubSpot may offer an extensive toolset, but it can't cater to every specialized industry need. That's where point solutions step in, offering highly customized options that HubSpot can't afford to focus on due to its broader customer base.But let's not underestimate HubSpot's adaptability. Ryan likens HubSpot to the Apple of martech—a comprehensive, seamless ecosystem. It's no longer just a canned platform; its extensibility allows for customization down to individual CRM cards and custom code, thus enabling companies to craft tailored solutions within its structure. In a way, HubSpot is morphing into a platform where you can build point solutions atop its robust foundation.Contrary to the perception of being solely HubSpot-focused, Ryan clarified that his agency is not strictly "tool agnostic," but they do possess expertise in any tool that complements or integrates with HubSpot. He recognizes that even with HubSpot's expansive features, there are instances when an external tool may be more fitting for a specific use case.Key Takeaway: If you're a business deciding between an all-in-one solution like HubSpot and a specialized point solution, know this: the ecosystem you choose will heavily influence your capabilities. You'll either embrace the depth of a niche tool or the breadth and adaptability of a platform like HubSpot. Make your choice based on your specific needs, not the general buzz in the industry.The Data Warehouse vs. HubSpot CRM: Where Should Your Data Live?When asked about the evolving role of data warehouses and HubSpot CRM as the "source of truth," Ryan provided an insightful two-part answer. On one hand, data warehouses are starting to integrate AI tools that could mimic functionalities like HubSpot's chatbot features. With these AI tools, you can query all customer data that's consolidated in the data warehouse, across various systems. Ryan believes that while these advancements are underway, HubSpot itself isn't inherently built to serve as a data warehouse. It excels in areas like usability and quick onboarding but falters in serving as a comprehensive data repository.The issue intensifies when teams have to toggle between multiple systems for a single task. Data loss and inefficiencies arise, especially when manual data transfer between systems is required. Ryan points out that this inefficiency can be mitigated by using CRM cards. These cards retrieve and action data not stored in HubSpot but are built into your HubSpot contact or deal record. They facilitate real-time connection with other systems like ERP for tasks such as inventory management or dynamic pricing. All of this is done without ever leaving HubSpot, making the process seamless and efficient.Yet, the fact remains that HubSpot shouldn't try to be your data warehouse, according to Ryan. Its design and functionality are geared towards user-friendliness and quick task execution. If you're dealing with complex data retrieval and queries, a dedicated data warehouse with AI capabilities is where you should be looking.However, the nuance here is that while HubSpot should not be your data warehouse, it can still serve as a hub to access that data. The CRM cards function as a practical bridge between HubSpot's easy-to-use interface and the heavy data lifting that takes place in a specialized data warehouse.Key Takeaway: HubSpot serves a specific need and does it well, but it's not designed to be a data warehouse. Leverage CRM cards to bridge the gap between HubSpot's user-friendly environment and the more complex, data-rich capabilities of a data warehouse. This way, you're not sacrificing efficiency or risking data loss.Navigating the Complex Landscape of Data Management in HubSpot ImplementationsWhen asked about the challenges that have evolved in the realm of data management and collection, especially with the rise of Google Analytics 4 and HubSpot's expanding capabilities, Ryan had a layered response. The HubSpot ecosystem itself has become significantly more complex over the years. What started as a simple inbound marketing tool has grown into a platform that encompasses CMS and Sales Hub, and it now finds itself in an even more complex martech ecosystem.Ryan emphasized that data attribution has become increasingly difficult to nail down. Unlike five years ago, marketers today face the challenge of eroding first-party and third-party data. Cookies are going away, forms are losing their appeal, and this makes it difficult to track precisely what drives revenue. In such a climate, data serves more as a directional indicator rather than a strict "source of truth."In terms of operational challenges, Ryan pointed out that the key is not to get bogged down in trying to capture every data point, which is both resource-draining and virtually impossible. Whether you're a small business with a one-person marketing team or a larger entity with a full-fledged marketing operations setup, the objective should be to collect what's reasonable for your scale.Ryan's perspective is a wake-up call. Trying to pinpoint an exact ROI down to the last cent is no longer feasible or even sensible. Instead, businesses should aim to get a directional sense from their data. HubSpot, with its user-friendly interface and versatile features, can serve as a reliable tool for that, even if it isn't built to be a data warehouse.Key Takeaway: Stop chasing an exact ROI from your data. Focus on gathering actionable insights that give you a directional sense of your marketing efforts. With the right approach, even amidst data challenges, platforms like HubSpot can be powerful allies.Navigating HubSpot's Maze: A Candid Take on Data Management and AttributionWhen asked about the operational challenges of implementing HubSpot and focusing on data attribution, Ryan offered a cautionary perspective. Shoving all your data into HubSpot isn't the move. Why? Because data overload leads to an intractable mess that becomes someone else's nightmare when your in-house HubSpot wizard moves on. Ryan advocates for a minimum viable product approach to data. Capture only what's absolutely essential for making informed decisions. The goal isn't to turn HubSpot into a dumping ground for data but to transform it into an effective tool for relevant, actionable insights.Ryan stressed that HubSpot's reporting functionality can be quite user-friendly when used effectively. Here's the low-down: create a deal-based custom report. Link any property on the deal record to your revenue numbers. He emphasizes the utility of HubSpot workflows, specifically the 'create a deal from a contact' action. By automating deal creation through workflows, you can copy any property from the contact record to the deal record. And why does this matter? It captures data at the time of the deal creation, giving you a snapshot of the customer's last interaction before conversion.Ryan pointed out one of HubSpot's significant limitations: its inability to effectively track a timeline of interactions over time. For example, if a contact fills out multiple forms that influence lifecycle stage changes, HubSpot won't intuitively show this data sequence. However, Ryan offered a workaround. At the moment a deal is created, capture the last form the contact filled out. This data will be preserved on the deal record, even if it changes on the contact record later. This strategy, Ryan argues, offers a valuable attribution tool within HubSpot's framework.For those getting lost in the nitty-gritty of data management, Ryan's approach simplifies it. Instead of grappling with a flood of information, focus on gathering only what's crucial for making effective decisions. Yes, HubSpot allows you to create detailed attribution reports. But simplicity and precision often trump complexity. Make it about actionable insights, not data hoarding.Key Takeaway: Don't turn HubSpot into a data landfill. Prioritize essential data that informs decision-making. Leverage HubSpot's 'create a deal from a contact' feature to link data to revenue effectively, and gain insights that are immediately actionable.Why HubSpot's Developer Portal is Your New Best Friend for LearningWhen asked about the ideal pathway for acquiring HubSpot skills, Ryan flipped the script entirely. Forget years of standard use or merely relying on HubSpot's official certifications. Ryan's game-changing insight? Anyone can set up a developer account on HubSpot, granting you access to enterprise-level tools. With this, you're not just restricted to learning; you're empowered to solve real-world problems in a sandbox environment.Ryan has been in the HubSpot game for almost a decade, but this revelation only came to him in the last year. The developer portal, he pointed out, enables you to take questions from communities, like those on LinkedIn, and then run experiments to find solutions. It's not just theoretical knowledge anymore; it's about rolling up your sleeves and digging into the weeds to resolve genuine issues. The aim isn't merely to understand HubSpot but to apply that knowledge in complex, real-world scenarios.It's not that Ryan discounts the value of HubSpot certifications. He actively encourages taking them to stay current. But where certifications can teach you the "what" and the "why," the developer portal teaches you the "how." The questions you encounter from the community are grounded in genuine business challenges, bringing you much closer to the day-to-day experiences you'll face with clients.The contrast couldn't be more stark between standard certifications and handling a client's live concerns. By using the developer portal, Ryan has shifted from passive learning to active problem-solving. You're not just being taught; you're learning by doing. In a landscape filled with ever-increasing tools and features, this hands-on approach may be the most beneficial way to stay ahead.Key Takeaway: Don't limit your HubSpot education to official certifications. Use HubSpot's developer portal to get hands-on experience with enterprise tools and solve real-world problems you encounter in online communities. This practical approach will fast-track your learning and make you a go-to HubSpot expert.The Power of Collective Expertise in Martech ToolsWhen asked about the complexities of becoming a specialist in a single martech tool versus a generalist in multiple platforms, Ryan offered some keen insights. According to him, the challenge for in-house marketers is manifold. These professionals often juggle tasks that leave them no room to stay updated on the consistent changes in tools like HubSpot, which practically churns out new features daily.Ryan emphasized the underestimated value of a community of experts within a consultancy or services company. Using his own experience at aptitude eight as an example, he illustrated that it's not about hiring one person with specialized knowledge, but rather tapping into a reservoir of collective intelligence. He recounted how the company's internal communication channels become a flurry of problem-solving activity whenever a client issue arises.Interestingly, Ryan attributed his own 'aha moments,' such as the comment he made on Mike Rizzo's post, to this collective wisdom. These insights don't solely come from his own experience; they're shared knowledge gained from ongoing conversations with colleagues. Ryan firmly believes that the power of many far outweighs the capability of one, especially when navigating the intricate world of martech tools that continuously evolve.The dialogue also addressed the question of whether small teams should rely on in-house expertise for managing tools like HubSpot or Iterable. Ryan's perspective makes it clear that the advantages of hiring a services company go beyond simple delegation. It's about leveraging a vast pool of information that is continually updated and shared across experts in the field.Key Takeaway: Don't underestimate the collective knowledge within a specialized consultancy. While an in-house expert may struggle to keep up with constant updates, a team of professionals can provide real-time solutions and avoid costly errors. In this fast-paced martech environment, the wisdom of the crowd is invaluable.The Imperative of Documentation in Marketing OperationsWhen asked about the challenges of change management in marketing operations, particularly with the turnover of employees, Ryan emphasized the critical role of documentation. Unlike many in-house teams that often neglect this step, his team ensures that every project or retainer is accompanied by comprehensive documentation. This comes in various forms—spreadsheets, loom videos, and detailed Word documents. The goal is straightforward: to create a seamless transition for clients or internal teams, especially when there's a change in the delivery team.This documentation-first approach tackles a significant gap in many organizations. Typically, an employee's departure over two weeks leaves a vacuum filled with undocumented tasks and processes. It's akin to trying to piece together a puzzle without knowing what the final picture looks like. Ryan's approach fills this gap and ensures that tasks don't fall between the cracks. They even use a well-structured project management system to track completed tasks, upcoming activities, and the state of different projects.But Ryan's advocacy for robust documentation doesn't end with client-facing projects; it extends to the internal team as well. Ryan praised his VP of People Operations for setting an example with an impeccable onboarding process that includes pre-recorded videos and walkthroughs for every piece of software used by the company. This recorded content serves as a resource that new hires can revisit, which is particularly helpful when absorbing a large amount of information in a short period.What sets Ryan and his team apart is that they've baked documentation into their operational DNA. They're not just doing it for clients or for transitions; they recognize it as a cornerstone of effective operations. Ryan candidly admits that even he could do more on this front, an acknowledgment that the process of documentation is an ongoing endeavor.Key Takeaway: Documentation isn't a one-off task or a box to be checked; it's an ongoing commitment that has a profound impact on the efficiency and resilience of an organization. Make it a part of your operations rather than an afterthought, and you'll find that changes and transitions become markedly easier to manage.Finding the Sweet Spot Between Career and Personal LifeWhen asked about how he manages to remain both happy and successful while juggling multiple roles, Ryan highlighted the significance of balance. "You have to make sure you're not dipping too far in one direction or another," he said. He touched upon a challenge many of us face—burnout. Diving too deep into work, according to Ryan, not only led to emotional exhaustion but also caused physical injuries. It's clear that imbalance in one area can have a domino effect on other parts of life.Ryan emphasized that maintaining this equilibrium isn't merely about managing work. It extends to ensuring you're getting enough sleep, exercise, and even a dash of outdoor activity. Ignoring any of these aspects can create a lopsided life that, in the long run, serves no one. Exercise stands out as a particularly important component, acting as a sort of anchor that helps to maintain a stable mental state, thereby enabling more effective work and a more fulfilling personal life.What's striking about Ryan's perspective is its simplicity. There's no magical formula or secret sauce for a balanced life. It comes down to fundamental aspects like sleep, physical activity, and time spent outdoors. His advice aligns with the well-documented idea that happiness and success don't always spring from extraordinary actions but often from getting the basics right.However, the real world always poses the challenge of application. Recognizing the need for balance is one thing; implementing it in the chaos of everyday life is another. But if we take a page out of Ryan's book, it starts by setting small, achievable goals for these fundamental aspects of life. After all, as he pointed out, the cost of imbalance is not just emotional but can have physical repercussions as well.Key Takeaway: Balance doesn't require revolutionary actions; it needs attention to basics like sleep, exercise, and a touch of the outdoors. The focus should be on maintaining this balance to prevent burnout and ensure both happiness and success.Episode RecapHubSpot is more than a CRM—it's a glimpse into the future of AI-driven business, and you can't afford to be left behind. If you're a tech founder, listen up: choosing whether to integrate AI isn't a 'maybe someday' decision. It's now. Don't let the slow adoption rates of HubSpot's new AI features fool you; marketers are is just catching up to what the tools can do. Your data is the fuel for this AI engine, but bad data? That's like throwing sand in the gas tank. If you're going to play the AI game, you've got to get your data house in order, period.HubSpot isn't a 'one-size-fits-all' solution, especially when it comes to data. Sure, it's user-friendly, but for the heavy data lifting, you'll still need a dedicated data warehouse. Where HubSpot shines is in its evolving adaptability. They're constantly adding functionalities, making it not just a CRM but part of an expanding martech universe. So, make your choice wisely. Are you looking for an all-in-one platform, or do you need specialized tools? Each path will define your capabilities, and this isn't a decision to make lightly.If you're striving to become a HubSpot pro, don't just settle for certifications. Dive into HubSpot's developer portal. It's not a playground; it's a training ground for tackling real-world problems. Here's your chance to go beyond the "what" and "why" and dig into the "how." Practical skills trump theory every single time.And let's talk collective smarts. In the fast-paced world of martech, even the sharpest in-house marketer can get swamped. That's where a specialized consultancy steps in. You're not just outsourcing tasks; you're tapping into a hive mind of expertise. This shared pool of knowledge is continually refreshed, giving you insights and solutions you couldn't get flying solo.Don't underestimate the grunt work of thorough documentation. It's not sexy, but it's the backbone of any successful operation. Documentation isn't just for the client transition; it's also a lifesaver for internal processes, especially when you're juggling team changes. It's not an extra—it's essential. Get it right, and you'll not only survive the inevitable team and tech changes, but you'll thrive. Now go on, give that episode a listen. It's packed with real talk you won't want to miss.If you're grappling with the complexities of AI, data attribution, and martech decision-making, this podcast episode is your roadmap. Ryan doesn't just skim the surface; he dives deep into actionable strategies for leveraging HubSpot, integrating AI, and maximizing your data quality. This isn't a passive listen; it's a call to action for anyone looking to be a front-runner in the rapidly evolving martech space. So don't miss out—listen to the episode and arm yourself with the insights to stay ahead

Guest Speaker: Søren Mathiasen, Software Engineer at Kapeta. In 2020, as the scale of operations and business grew, software teams at Spotify were starting to suffer. The continuous context switching, cognitive overload, and fragmented infrastructure all led to engineers becoming less productive. Thus Backstage was born, an internal developer portal (IDP) powered by a centralized software catalog. In this episode, we continue to explore Backstage and the benefits it brings. Our guest, Soren Mathiasen, a software engineer, shares with us his experience implementing Backstage for two companies experiencing rapid growth. He explains how Backstage helped improve the efficiency and effectiveness of software development teams. Tune in to hear his insights and experience! 

Kenneth Rose, CTO at OpsLevel, joins Corey on Screaming in the Cloud to discuss how OpsLevel is helping developer teams to scale effectively. Kenneth reveals what a developer portal is, how he thinks about the functionality of a developer portal, and the problems a developer portal solves for large developer teams. Corey and Kenneth discuss how to drive adoption of a developer portal, and Kenneth explains why it's so necessary to have executive buy-in throughout that process. Kenneth also discusses how using their own portal internally along with seeking out customer feedback has allowed OpsLevel to make impactful innovations. About KenKenneth (Ken) Rose is the CTO and Co-Founder of OpsLevel. Ken has spent over 15 years scaling engineering teams as an early engineer at PagerDuty and Shopify. Having in-the-trenches experience has allowed Ken a unique perspective on how some of the best teams are built and scaled and lends this viewpoint to building products for OpsLevel, a service ownership platform built to turn chaos into consistency for engineering leaders.Links Referenced: OpsLevel: https://www.opslevel.com/ LinkedIn: https://www.linkedin.com/company/opslevel/ Twitter: https://twitter.com/OpsLevelHQ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn, about, oh I don't know, two years ago and change, I wound up writing a blog post titled, “Developer Portals are An Anti Pattern,” and I haven't really spent a lot of time thinking about them since. This promoted guest episode is brought to us by our friends at OpsLevel, and they have sent their CTO and co-founder Ken Rose, presumably in an attempt to change my perspective on these things. Let's find out. Ken, thank you for agreeing to, well, run the gauntlet, for lack of a better term.Ken: Hey, Corey. Thanks again for having me. And I've heard, you know, heard and listened to your show a bunch, and really excited to be here today.Corey: Let's begin with defining our terms. I'm curious to know what a developer portal is. ‘What would you say a developer portal means to you?' Like it's a college entrance essay.Ken: Right? Definitely. You know, so really, a developer portal is this consolidated place for developers to come to, especially in large organizations to be able to get their jobs done more easily, right? A large challenge that developers have in large organizations, there's just a lot to do and a lot to take care of. So, a developer portal is a place for developers to be able to better own, manage, and run the services, they're responsible for that run in production, and they can do that through access, easy access to self-service tooling.Corey: I guess, on some level, this turns into one of those alignment charts of, like, what is a database and, like, how prescriptive you want to be. It's like, well is a senior engineer a database because you can query them and they have information? Would you consider, for example, Kubernetes be a developer platform, and/or would the AWS console?Ken: Yeah, that's actually an interesting question, right? So, I think there's actually two—we're going to get really niggly here—there's developer platform and developer portal, right? And the word portal for me is something that sits above a developer platform. I don't know if you remember, like, the late-90s, early-2000s, like, portals were all the rage.Like, Yahoo and AltaVistas were like search portals, they were trying to, at the time, consolidate all this information on a much smaller internet to make it easy to access. A developer portal is sort of the same thing, but custom-built for developers and trying to consolidate a lot of the tooling that exists. Now, in terms of the AWS console? Yeah, maybe. Like, it has a suite of tools and suite of offerings. It doesn't do a lot on the well, how do I quickly find out what's running in production and who is responsible for it? I don't know, unless AWS shipped, like, their, you know, three-hundredth new offering in the last week that I haven't, you know, kept on top of.But you know, there's definitely some spectrum in terms of what goes into a developer portal. For me, there's kind of three main things you need. You do need some kind of a catalog, like, what's out there who owns it; you need some kind of a way to measure, like, how good are those services, like, how well built are they; and then you need some access to self-service tooling. And that last part is where, like, the Kubernetes or AWS could be, you know, sort of a dev portal as well.Corey: My experience with developer portals—there was a time when I loved it. RightScale was what I used—at some depth—back in I want to say 2010, 2011 because the EC2 console was clearly not built or designed by anyone who had not built EC2 themselves with their bare hands and sweat of their brow. And in time, the EC2 console got better where it wasn't written in hieroglyphics, as best we could tell, and it became ‘click button to launch instance.' And RightScale really didn't have a second act and they wound up getting acquired by our friends over at Flexera years later. And I haven't seen their developer portal in at least eight years as a direct result of this.So, the problem, at least when I was viewing it purely in the context of AWS services, it feels like you are competing against AWS iterating forward on developer experience, which they iterate slowly, sometimes, and unevenly across their breadth of services, but it does feel like at some level by building an internal portal, you are, first, trying to out-innovate AWS, in some ways, and two, you are inherently making the trade-off of not using recent features and enhancements that have not themselves been incorporated into the portal. That's where the, I guess the start, the genesis of my opposition to the developer portal approach comes from. Is that philosophy valid these days? Not as much. Because I can see an argument for it shifting.Ken: Yeah, I think it's slightly different. I think of a developer portal as again, it's something that sort of sits on top of AWS or Google Cloud or whatever cloud provider use, right? You give an example for example with RightScale and EC2. So, provisioning instances is one part of the activity you have to do as a developer. Now, in most modern organizations, you have, like, your product developers that ship features. They don't actually care about provisioning instance themselves. There are another group called the platform engineers or platform group that are responsible for building automation and tooling to help spin up instances and create CI/CD pipelines and get everything you need set up.And they might use AWS under the covers to do that, but the automation built on top and making that accessible to developers, that's really what a developer portal can provide. In addition, it also provides links to operational tooling that you need, technical documentation, it's everything you need as a developer to do your job, in one place. And though AWs bills itself is that, I think of them as more, they have a lot of platform offerings, right, they have a lot of infra-offerings, but they still haven't been able to, I think, customize that, unless you're an organization that builds—that has kind of gone in-all on AWS and doesn't build any of your own tooling, that's where a developer portal helps. It really helps by consolidating all that information in one place, by making that information discoverable for every developer so they have less… less cognitive load, right? We've asked developers to kind of do too much that we don't… we've asked to shift left and well, how do we make that information more accessible?Regarding the point of, you know, AWS adds new features or new capabilities all the time and, like, well you have this dev portal, that's sort of your interface for how to get things done. Like, how will you use those? Dev portal doesn't stop you from doing that, right? So, my mental model is, if I'm a developer, and I want to spin up a new service, I can just press a button inside of my dev portal in my company and do that. And I have a service that is built according to the latest standards, it has a CI/CD pipeline, it already has a—you know, it's registered in PagerDuty, it's registered in Datadog, it has all the various bits.And then there's something else that I want to do that isn't really on the golden path because maybe this is some new service or some experiment, nothing stops us from doing that. Like, you still can use all those tools from AWS, you know, kind of raw. And if those prove to be valuable for the rest of the organization, great. They can make their way into the dev portal; they can actually become a source of leverage. But if they're not, then they can also just sit there on the vine. Like, not everything that eight of us ever produces will be used by every company.Corey: Many years ago, I got a Cisco pair of certifications because recession was hitting and I needed to be better at networking. And taking those certifications, in those days before Cisco became the sad corporate dragon with no friends we all know today, they were highly germane and relevant. But I distinctly remember, even now, 15 years later, that there was this entire philosophy of pretend that the entire world is Cisco only, which in networking is absolutely never true. It feels like a lot of the AWS designs and patterns tend to assume, oh yeah, you're going to use AWS services for everything. I have never yet found that to be true, other than when I'm just trying to be obstinate.And hell is interoperability between a bunch of different things. Yes, I may want to spin up an EC2 instance and an AWS load balancer and some S3 storage or whatnot, but I'm also going to want to monitor it with PagerDuty, I'm going to want to have a CDN that isn't CloudFront because most CDN these days don't hate you in quite the same economic ways and are simpler to work with, et cetera, et cetera, et cetera. So, there's definitely a story wherein I've found that there's an—the interoperability of tying these things together is helpful. How do you avoid falling down the trap of oh, everyone should be multi-cloud, single pane of glass at cetera, et cetera? In practice that always seems to turn to custard.Ken: Yeah, I think multi-cloud and single pane of glass are actually two different things. So multi-cloud, like, I agree with you to some sense. Like, pick a cloud and go with it, like, unless you have really good business reasons to go for multi-cloud. And sometimes you do, like, years ago, I worked at PagerDuty, they were multi-cloud for a reliability reason, that hey, if one cloud provider goes down, you don't want [crosstalk 00:08:40]—Corey: They were an example I used all the time for that story—Ken: Right.Corey: —specifically the thing woke you up was homed in a bunch of different places, whereas the marketing site, the onboarding flow, the periphery stuff around it was not because it didn't need to be.Ken: Exactly.Corey: Like, the core business need of wake you up was very much multi-cloud because once upon a time, it wasn't and it went down with the rest of us-east-1 and people weren't woken up to be told their site was on fire.Ken: A hundred percent. And on the kind of like application side where, even then, pick a cloud and go with it, unless there's a really compelling business reason for your business to go multi-cloud. Maybe there's something credits or compliance or availability, right? There might be reasons, but you have to be articulate about whether they're right for you.Now, single pane of glass, I think that's different, right? I do think that's something that, ultimately, is a net boon for developers. In any large organization, there is a myriad of internal tools that have been built. And it's like, well, how do I provision a new topic in the Kafka cluster? How do I actually get access to the AWS console? How do I spin up a new service, right? How do I kind of do these things?And if I'm a developer, I just want to ship features. Like, that's what I'm incented to do, that's what I'm optimizing for. And all this other stuff I have to do as part of my job, but I don't want to have to become, like, a Kubernetes guru to be able to do it, right? So, what a developer portal is trying to do is be that single pane of glass, bringing all these common set of tools and responsibilities that you have as a developer in one place. They're easy to search for, they're easy to find, they're easy to query, they're easy to use.Corey: I should probably have asked this earlier on, but let's disambiguate for a little bit here. Because when I'm setting up to use a new service or product and kick the tires on it, no two explorations really look the same. Whereas at most responsible mature companies that are building products that are—services that are going to production use, they've standardized around a number of different approaches. What does your target customer look like? Is there a certain point of scale, a certain level of complexity, a certain maturity of process?Ken: Absolutely. So, a tool like OpsLevel or a developer portal really only makes sense when you hit some critical mass in terms of the number of services you have running in production, or the number of developers that you have. So, when you hit 20, 30, 50 developers or 20, 30, 50 services, an important part of a developer portal is this catalog of what's out there. Once you kind of hit the Dunbar number of services, like, when you have more than you keep in your head, that's when you start to need tooling like this. If you look at our customer base, they're all you know, kind of medium to large-sized companies. If you're a startup with, like, ten people, OpsLevel is probably not right for you. We use all playable internally at OpsLevel, and you know, like, we're still a small company. It's like, we make it work for us because we know how to get the most out of it, but like, it's not the perfect fit because it's not really meant for, you know, smaller companies.Corey: Oh, I hear you. I think I'm probably… I have a better AWS bill analytic system running internally here at The Duckbill Group than some banks do. So, I hear you on that front.Ken: I believe it.Corey: But also implies to me that there's no OpsLevel prospect or customer deployment that has ever been greenfield. It's always you're building existing things, there's already infrastructure in place, vendors have been selected across the board. You aren't—don't to want to starting a company day one, they're going to all right, time to spin up our AWS account and we're also going to wind up signing up for OpsLevel, from the sound of it.Ken: Correct—Corey: Accurate? Inaccurate?Ken: I think that's actually accurate. Like, a lot of the problems, we solve other problems that come as you start to scale both your product and your engineering team. And it's the problems of complexity.Corey: What do those painful problems look like? In other words, what is someone sitting at home right now listening to this, or driving to work debating whether want to ram a bridge abutment or go into the office depending on their mental state today, what painful problem did they have that OpsLevel is designed to fix?Ken: Yeah, for sure. So, let's help people self-select. So, here's my mental model for any [unintelligible 00:12:25]. There are product developers, platform developers, and engineering leaders. Product developers, if you're asking questions like, “I just got paged for the service. I don't know what this does.” Or, “It's upstream from here. Where do I find the technical documentation?” Or, “I think I have to do something with the payment service. Where do I find the API for that?”You know, when you get to that scale, a developer portal can help you. If you're a platform engineer and you have questions like, “Okay, we got to migrate. We're migrating, I don't know, from Datadog to Honeycomb, right? We got to get these fifty or a hundred or thousands of services and all these different owners to, like, switch to some new tool.” Or, “Hey, we've done all this work to ship the golden path. Like, how to actually measure the adoption of all this work that we're doing and if it's actually valuable?” Right?Like, we want everybody to be on a certain set of CI tooling or a certain minimum version of some library or framework. How do we do that? How do we measure that? OpsLevel is for you, right? We have a whole bunch of stuff around maturity.And if you're engineering leader, ultimately, questions you care about, like, “How fast are my developers working? I have this massive team, we've made this massive investment in hiring all these humans to write software and bring value for our customers. How can we be more efficient as a business in terms of that value delivery?” And that's where OpsLevel can help as well.Corey: Guardrails, whether they be economic, regulatory, or otherwise, have to make it easier than doing things incorrectly because one of the miracle aspects of cloud also turns into a bit of a problem, which is shadow IT is only ever a corporate credit card away. Make it too difficult to comply with corporate policies and people won't. And they're good actors; they're trying to get work done. They're not trying to make people's lives harder, but they don't want to spend six weeks provisioning an EC2 cluster. So, there's always that weird trade-off.Now, it feels—and please correct me if I'm wrong—once someone has rolled out OpsLevel at their organization, where it really shines is spinning up a new service where okay, great, you're going to spin up the automatic observability portion of it, you're going to spin up the underlying infrastructure in certain ways that comply with our policies, it's going to build the CI/CD pipelines around it, you're going to wind up having the various cost instrumentation rolled out to it. But for services that are already excellent within the environment, is there an OpsLevel story for them?Ken: Oh, absolutely. So, I look at it as, like, the first problem OpsLevel helps solve is the catalog and what's out there and who owns it. So, not even getting developers to spin up new services that are kind of on the golden path, but just understanding the taxonomy of what are the services we have? How do those services compose into higher-level things like systems or domains? What's the whole set of infrastructure we have?Like, I have 50 AWS accounts, maybe a handful of GCP ones, also, some Azure. I have all this infrastructure that, like, how do I start to get a handle on, like, what's out there in prod and who's responsible for it. And that helps you get in front of compliance risks, security risks. That's really the starting point for OpsLevel building that catalog. And we have a bunch of integrations that kind of slurp all this data to automatically assemble that catalog, or YAML as well if that's your thing. But that's the starting point is building that catalog and figuring out this assignment of, like, okay, this service and this human, or this—sorry—team, like, they're paired together.Corey: A number of offerings in this space, which honestly, my exposure to it is bounded simultaneously to things that are ten years old and no one uses anymore, or a bunch of things I found on GitHub. And the challenge that both of those products tend to have is that they assume certain things to be true about a given environment: that they're using Terraform to manage everything, or they're always going to be using CloudFormation, or everyone there knows Python or something else like that. What are the prerequisites to get started with OpsLevel?Ken: Yeah, so we worked pretty hard to build just a ton of integrations. I would say integrations is are just continuing thing we have going on in the background. Like, when we started, like, we only supported a GitHub. Now, we support all the gits, you know, like GitHub, GitLab, Bitbucket, Azure DevOps, like, we're building [unintelligible 00:16:19]. There's just a whole, like, long tail of integrations.The same with APM tooling. The same with vulnerability management tooling, right? And the reason we do that is because there's just this huge vendor footprint, and people, you know, want OpsLevel to work for them. Now, the other thing we try to do is we also build APIs. So, anything we have as, like, a core integration, we also have kind of like an underlying API for, so that there's, no matter what you have an escape hatch. If like, you're using some tool that we don't support or you have some homegrown thing, there's always a way to try to be able to integrate that into OpsLevel.Corey: When people think about developer portals, the most common one that pops to mind is Backstage, which Spotify wound up building, internally, championing, open-sourcing, and I believe, on some level, turned into a product because if there's one thing people want, it's to have their podcast music company become a SaaS vendor, which is weird to me. But the criticisms that I've seen about and across the board have rung relatively true, including from people internal at Spotify who have used the thing, which is, well first is underestimating the amount of effort that is necessary to maintain Backstage itself, that the build versus buy discussion is always harder to bu—engineers love to build, but they shouldn't be building things outside of their core competency half the time, and the other is driving adoption within the org where you can have the most amazing developer portal in the known universe, but if people don't use it, it may as well not exist and doing the carrot and stick approach often doesn't work. I think you have a pretty good answer that I need not even ask you to elaborate on, “Well, how do we avoid having to maintain this ourselves,” since you have a company that does this, but how do you find companies are driving adoption successfully once they have deployed OpsLevel?Ken: Yeah, that's a great question. So, absolutely. Like, I think the biggest thing you need first, is kind of cultural buy-in and that this is a tool that we want to invest in, right? I think one of the reasons Spotify was successful with Backstage and I think it was System Z before that was that they had this kind of flywheel of, like, they saw that their developers were getting, you know better faster, working happier, by using this type of tooling, by reducing the cognitive load. The way that we approach it is sort of similar, right?We want to make sure that there is executive buy-in that, like, everybody agrees this is, like, a problem that's worth solving. The first step we do is trying to build out that catalog again and helping assign ownership. And that helps people understand, like, hey, these are the services I'm responsible for. Oh, look, and now here's this other context that I didn't have before. And then helping organizations, you know, what—it depends on the problem we're trying to solve, but whether it's rolling out self-serve automation to help developers, like, reduce what was before a ton of cognitive load or if it's helping platform teams define what good looks like so they can start to level up the overall health of what's running in production, we kind of work on different problems, but it's picking one problem and then you know, kind of working with the customers and driving it forward.Corey: On some level, I think that this is going to be looked down upon inherently just by automatic reflex of folks with infrastructure engineering backgrounds. It's taken me some time to learn to overcome my own negative reaction to it. Because it's, I'm here to build things and I want to build things out in such a way that it's portable and reusable without having to be tied to a particular vendor and move on. And it took me a long time to realize that what that instinct was whispering in my ear was in fact, no, you should be your own cloud provider. If that's really what I want to do, I probably should just brush up on you know, computer science trivia from 20 years ago and then go see if I can pass Google's SRE interview.I'm not here to build the things that just provision infrastructure from scratch every company I wind up landing at. It feels like there's more important, impactful work that I can do. And let's be clear, people are never going to follow guardrails themselves when they have to do a bunch of manual steps. It has to be something that is done for them. And I don't know how you necessarily get there without having some form of blueprint or something like that, provided for them with something that is self-service because otherwise, it's not going to work.Ken: I a hundred percent agree, by the way, Corey. Like, the take that, like, automation is the only way to drive a lot of this forward is true, right? If for every single thing you're trying—like, we have a concept called a rubric and it's basically how you measure the service health. And you can—it's very customizable, you have different dimensions. But if, for any check that's on your rubric, it requires manual effort from all your developers, that is going to be harder than something you can just automate away.So, vulnerability management is a great example. If you tell developers, “Hey, you have to go upgrade this library,” okay, some percentage [unintelligible 00:20:47], if you give developers, “Here's a pull request that's already been done and has a test passing and now you just need to merge it,” you're going to have a much better adoption rate with that. Similarly with, like, applying templates being able to [up-level 00:20:57], you know, kind of apply the latest version of a template to an existing service, those types of capabilities, anything where you can automate what the fixes are, absolutely you're going to get better adoption.Corey: As you take a look at your existing reference customers—which is something I always look for on vendor websites because, like, oh, we have many customers who will absolutely not admit to being customers, it's like, that sounds like something that's easy to say—you have actual names tied to these things. Not just companies, but also individuals. If you were to sit down and ask your existing customer base, “So, why did you wind up implementing OpsLevel and what has the value that's delivered to you been since that implementation?” What do they say?Ken: Definitely. I actually had to check our website because we, you know, land new customers and put new logos on it. I was like, “Oh, I wonder what the current set is out right now?”Corey: I have the exact same challenge. Like oh, we have some mutual customers. And it's okay. I don't know if I can mention them by name because I haven't checked our own list of testimonials [unintelligible 00:21:51] lately because say the wrong thing and that's how you wind up being sued and not having a company anymore.Ken: Yeah. So, I don't—I definitely, you know, want to stay [on side 00:22:00] on that part, but in terms of, like, kind of sample reference customer, a lot of the folks that we initially worked with are the platform teams, right? They're the teams that care about what's out there, and they need to know who's responsible for it because they're trying to drive some kind of cross-cutting change across the entire, you know, production footprint. And so, the first thing that generally people will say is—and I love this quote. This came—I won't name them, but like, it's in one of our case studies.It was like, “I had, like, 50 different attempts at making a spreadsheet and they're all, like, in the graveyard, like, to be able to capture what's out there and who's responsible for it.” And just OpsLevel helping automate that has been one of the biggest values that they've gotten. The second point, then is now be able to drive maturity and be able to measure how well those services are being built. And again, it's sort of this interesting thing where we start with the platform teams. And then sometime later security teams find out about OpsLevel, and they're like, “Oh, this is a tool I can use to, like, get developers to do stuff? Like, I've been trying to get developers to do stuff for the longest time.”And they—I file Jira tickets and they just sit there and nothing gets done. But when it becomes part of this, like, overall health score that you're trying to increase a part of the across the board, yeah, it's just a way to kind of drive action.Corey: I think that there's a dichotomy of companies that emerge. And I tend to see the world through a lens of AWS bills, so let's go down that path. I feel like there are some companies presumably like OpsLevel, whereas if I—assuming you're running on top of AWS—if I were to pull your AWS bill, I would see upwards of 80% of your spend is going to be on this application called OpsLevel, the service that you provide to people. As opposed to the other side of the world, which is large enterprises, where they're spending hundreds of millions of dollars a year, but the largest application they have is a million-and-a-half a year in spend because just, they have thousands of these things scattered everywhere. That latter case is where I tend to see more platform teams, where I start to see a lot of managing a whole bunch of relatively small workloads. And developer platforms really seem to be where a lot of solutions lead, whereas 80% of our workload is one application, we don't feel the need for that as much. Is that accurate? Am I misunderstanding some aspect of it?Ken: No, a hundred percent you'd hit the nail on the head. Like, okay, think about the typical, like, microservices adoption journey. Like, you started with, you know, some small company—like us—you started with a monolith. Ah, maybe you built out a second app—Corey: Then you read on Hacker News and realize, “Oh, if we want to hire people, we've got to be doing what all the cool kids are up to.”Ken: Right. We got a microservice all the thing—but that's actually you know, microservices should come later, right, as a response to you needing scale your org and scale your—Corey: As someone who started building some application with microservices, I could not agree more.Ken: A hundred percent. So, it's as you're starting to take steps to having just more moving parts in your production infrastructure, right? If you have one moving part, unless it's like a really large moving part that you can internally break down, like, kind of this majestic monolith where you do have kind of like individual domains that are owned by different teams, but really the problem we're trying to solve, it's more about, like, who owns what. Now, if that's a single atomic unit, great, but can you decompose that? But if you just have, like, one small application, kind of like the whole team is owning everything, again, a developer portal is probably not the right tool for you. It really is a tool that you need as you start to scale your engineer work and as you start to scale the number of moving parts in your production infrastructure.Corey: I tended to use to think of that in terms of boring companies versus innovative ones and I don't think that's accurate. I think it is the question of maturity and where companies lead to. On some level, of OpsLevel starts growing and becomes larger and larger in different ways and starts doing acquisitions and launching into other areas, at some point, you don't have just one product offering, you have a multitude of them. At which point having something like that is going to be critical. But I have to ask, given that you are sort of not exactly your target customer profile, what are the sharp edges been on using it for your use case?Ken: Yeah. So, we actually have an internal Slack channel, we call OpsLevel on OpsLevel. And finding those sharp edges actually has been really useful for us. You know, all the good stuff, dogfooding and it makes your own product better. Okay, so we have our main app, we also do have a bunch of smaller things and it's like, oh yeah, you know, we have, like, I don't know, various Hackaday things that go on, it's important we kind of wind those down for, you know, compliance, we have our marketing site, we have, like, our Terraform.Like, so there's, like, stuff. It's not, like, hundreds or thousands of things, but there's more than just the main app. The second though, is it's really on the maturity piece that we really try to get a lot of value out of our own product, right? Helping—we have our own platform team. They're also trying to drive certain initiatives with our product developers.There is that usual tension of our, like, our own product developers are like, “I want to ship features.” What's this security thing I have to go take care of right now? But OpsLevel itself, like, helps reflect that. We had an operational review today and it was like, “Oh, this one service is actually now”—we have platinum as a level. It's in gold instead of platinum. It's like, “Why?” “Oh, there's this thing that came up. We got to go fix that.” “Great. Let's go actually go fix that so we're back into platinum.”Corey: Do you find that there's often a choice you have to make internally, where you could make the product more effective for your specific use case, but that also diverges from where your typical customer needs or wants the product to go?Ken: No, I think a lot of the things we find for our use case are, like, they're more small paper cuts, right? They're just as we're using it, it's like, “Hey, like, as I'm using this, I want to see the report for this particular check. Why do I have to click six times to get?” You know, like, “Wouldn't it be great if we had a button?” Right?And so, it's those type of, like, small innovations that kind of come up. And those ultimately lead to, you know, a better product for our customers. We also work really closely with our customers and developers are not shy about telling you what they don't like about your product. And I say this with love, like, a lot of our customers give us phenomenal feedback just on how our product can be better and we try to internalize that and you know, roll that feedback into the product.Corey: You have a number of integrations of different SaaS providers, infrastructure providers, et cetera, that you wind up working with. I imagine that given your scale and scope and whatnot, those offerings are dictated by what customers say, “Hey, we're using this thing. Are you going to support that or are you not going to maintain our business?” Which is a great way to wind up financing a lot of product development and figuring out what matters to people. My question for you is, if you look across the totality of your user base, what are the most popularly used integrations, if you can say?Ken: Yeah, for sure. I think right now—I could actually dive in to pull the numbers—GitHub and GitLab—or… I think GitHub, like, has slightly more adoption across our customer base. At least with our customers, almost nobody uses Bitbucket. I mean, we have, like, a small number, but, like, it's… I think, single-digit percentage. A lot of people use PagerDuty, which you know, hey, I'm an ex-PagerDuty person [crosstalk 00:28:24] and I'm glad to see that.Corey: I have a free tier PagerDuty account that will automatically page me for my home automation stuff. Specifically, if you know, the fire alarm goes off. Like, yeah, okay, there are certain things I want to be woken up for, but it's a very short list.Ken: Yeah, it's funny, the running default message when we use a test PagerDuty was, “The server is on fire.” [unintelligible 00:28:44] be like, “The house is on fire.” Like you know, go get that taken care of. There's one other tool so that's used a lot. Datadog actually is used a ton by just across our entire customer base, despite its… we're also Data—we're a Datadog partner, we're a Datadog customer, you know? It's not cheap, but it's a good product for, you know, monitoring and logs and there are [crosstalk 00:29:01]—Corey: No other than cloud infrastructure providers, I get the number one most common source of inquiries is Datadog optimization. It has now risen to a board-level concern in many cases because observability is expensive. That's a sign of success, on some level. Meanwhile, I'm sitting here, like, Date-a-dog? Oh, my God, that's disgusting. It's like Tinder for Pets. Which it turns out is not at all what they do.Ken: Nice.Corey: Yeah.[audio break 00:29:23]—optimizing their Slack integrations, their GitHub integration, et cetera. Or are they starting with the spinning up the servers piece of it?Ken: A lot of the time—and again, that first problem they're trying to solve is just get me a handle on everything we have running in production. You know, if you have multiple AWS accounts, multiple Kubernetes clusters, dozens or even hundreds of teams, God help you if you're going to try to, like, build a list manually to consolidate all that information. That's really the first part is, like, integrate Kubernetes, integrate your CI/CD pipelines, integrate Git, integrate your Cloud account, like, will integrate with everything and will try to build that map of, like, here's everything that's out there, and start to try to assign it to, like, and here's people that we think might be responsible in terms of owning the software. That's generally the starting point.Corey: Which makes an awesome amount of sense. I think going at it from the infrastructure first perspective is where I've seen most developer platforms founder. And to be fair, the job is easier now than it was years ago because it used to be that you were being out-innovated by AWS constantly. Innovation has slow down there. And you know that because of how much they say the pace of innovation has only sped up.And whenever AWS says something in a marketing context, they're insecure about it. I've learned this through the fullness of time observing that company. And these days, most customers do not use the majority of features available for any given service. They have solidified to a point where you can responsibly build on top of these things. Now, it seems that the problem is all the ‘yes, and' stuff that gets built on top of it.Ken: Yeah. Do you have an example, actually, like, one of the kinds of, like, ‘yes, and' tools that you're thinking about?Corey: Oh, absolutely. We have a bunch of AWS environment stuff so we should configure CloudWatch to look at all these things from an observability perspective. No, you should not. You should set up Datadog. And the first time someone does that by hand, they enable all have the observability and the rest and suddenly get charged approximately the GDP of Guam.And okay, maybe we shouldn't do that because then you have the downstream impact of that on your CloudWatch bill. So okay, how do we optimize this for the observability piece directly tied to that? How do we make sure that we get woken up when the site is down or preferably before that, but not every time basically, a EBS volume starts to get a little bit toasty? You have to start dialing this stuff in. And once you've found a lot of those aspects, being able to templatize that and roll that out on an ongoing basis and having the integrations all work together feels like it's the right problem to be solving.Ken: Yeah, absolutely. And the group that I think is responsible for that kind of—because it's a set of problems you described—is really, like, platform teams. Sometimes service owners for like, how should we get paged, but really, what you're describing are these kind of cross-cutting engineering concerns that platform teams are uniquely poised to help solve in an [unintelligible 00:32:03] organization, right? I was thinking what you said earlier. Like, nobody just wants to rebuild the same info over and over, but it's sort of like, it's not just building an [unintelligible 00:32:09]; it's kind of like solving this, like, how do we ship? Can we actually run stuff in prod? And not just run it but get observability and ensure that we're woken up for it and, like, what's that total end-to-end look like from, like, developers writing code to running software in production that's serving traffic? And solving all the problems [unintelligible 00:32:24], that's what I think of was platform engineering.Corey: So, my last question before we wind up wrapping this episode comes down to, I am very adept at two different programming languages, and those are brute force and enthusiasm. What implementation language is most of what you find yourself working with? And why is it in invariably going to be YAML?Ken: Yeah, that's a great question. So, I think there's, in terms of implementing OpsLevel and implementing a service catalog, we support YAML. Like, you know, there's this very common workflow, you just drop a YAML spec, basically, in your repo, if you're a service owner. And that, we can support that. I don't think that's a great take, though.Like, we have other integrations. Again, if the problem you're trying to solve is I want to build a catalog of everything that's out there, asking each of your developers hey, can you please all write YAML files that, like, describe the services you own and drop them into this repo? You've inverted this, like, database that essentially you're trying to build, like, what's out there and stored it in Git, potentially across several hundreds or thousands of repos. You put a lot of toil now on individual product developers to go write and maintain these files. And if you ever had to, like, make a blanket update to these files, there's no atomic way to kind of do that, right?So, I look at YAML as, like, I get it, you know? Like, we use the YAML for all the things in DevOps, so why not their service catalog as well, but I think it's toil. Like, there are easier ways to build a catalog. By, kind of, just integrate. Like, hook up AWS, hook up GitHub, hook up Kubernetes, hook up your CI/CD pipeline, hook up all these different sources that have information about what's running in prod, and let the software, let the tool, automatically infer what's actually running as opposed to requiring humans to manually enter data.Corey: I find that there are remarkably few technical holy wars that I cannot unify both sides on by nominating something far worse. Like, the VI versus Emacs stuff, the tabs versus spaces, and of course, the JSON versus YAML folks. My JSON versus YAML answer is XML: God's language. I find that as soon as you suggest that, people care a hell of a lot less about the differences between JSON and YAML because their job is to now kill the apostate, which is me.Ken: Right. Yeah. I remember XML, like, oh, man, 2002. SOAP. I remember SOAP as a protocol. That was a thing.Corey: Some of the earliest S3 API calls were done in SOAP, and I think they finally just used it to wash their mouths out when all was said and done.Ken: Nice. Yeah.Corey: I really want to thank you for taking the time to do your level best to attempt to convert me, and I would argue in many respects, you have succeeded. I'm thinking about this differently than I did half an hour ago. If people want to learn more, where's the best place for them to find you?Ken: Absolutely. So, you can always check out our website, opslevel.com. We're also fairly active on LinkedIn. If Twitter hasn't imploded by the time this episode becomes launched, then they can also check us out at twitter.com/OpsLevelHQ. We're always posting, just different content on, like, how to be successful with service maturity, DevOps, developer productivity, so that you know, ultimately, that you can ship out to customers faster.Corey: And we will, of course, put links to that in the [show notes 00:35:23]. Thank you so much for taking the time, not just to speak with me, but also for sponsoring this episode. It is appreciated.Ken: Cheers.Corey: Ken Rose, CTO and co-founder at OpsLevel. I'm Cloud Economist Corey Quinn and this has been a promoted guest episode of Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment which, upon further reflection, you could have posted to all of the podcast platforms if only you had the right developer platform to pull it off.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Karl's team at American Airlines were early adopters of Backstage, and in this episode he shares their journey of implementing and rolling out a developer portal. He also describes two of the extensions his team has built for their portal. Discussion points: (1:24) Where the idea of building a developer portal came from (7:24) What the developer experience looked like before the portal  (10:41) Initiating the project (14:16) The decision to choose Backstage  (16:28) The V1 scope for the portal  (19:14) Getting adoption for the portal (23:35) Defining success for the portal's adoption  (28:04) The ideal state for how developers will use the portal (30:56) Who should or shouldn't invest in building a developer portal  (33:14) Custom extensions Karl's team has developed for their portal (37:46) What's difficult about developing a new plugin for the backstage platform ‍Mentions and links:Follow Karl on LinkedInThe Runway platform at American Airlines Read more on the engineering blog from American Airlines 

As a meeting organizer or participant, take Microsoft Teams to the next level with advanced capabilities for personalization, deeper AI integration, and better meeting protection with Microsoft Teams Premium. For Teams admins, see the easy steps to enable Teams Premium, as well as your configuration options. Jeremy Chapman, Director of Microsoft 365, gives a hands-on tour for customized, intelligent, and secure meetings. ► QUICK LINKS: 00:00 - Introduction 00:25 - Custom branding & Meeting Templates 01:38 - Translated captions and intelligent recap 03:08 - Enhanced security- watermarking 04:12 - Virtual appointments 05:05 - Webinars 06:12 - Admin experience 08:51 - Wrap up ► Link References: Check out Microsoft Teams Premium at https://aka.ms/TeamsPremiumMechanics Build and customize Together modes with the Developer Portal at https://dev.teams.microsoft.com ► Unfamiliar with Microsoft Mechanics? As Microsoft's official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. • Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries • Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog • Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/website • To get the newest tech for IT in your inbox, subscribe to our newsletter: https://www.getrevue.co/profile/msftmechanics ► Keep getting this insider knowledge, join us on social: • Follow us on Twitter: https://twitter.com/MSFTMechanics • Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ • Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ • Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics 

È possibile gestire tutto il sistema quando l'organizzazione scala? Relazioni e interdipendenza tra servizi può creare contesti improduttivi e confusi, esiste però un modo tutto opensource per migliorare la situazione, si tratta di backstage l'internal developer portal estendibile creato in casa Spotify. Ne abbiamo parlato con Francesco Corti, product manager appunto, di Backstage che ci ha raccontato come funziona e molto altro.- https://it.linkedin.com/in/fcorti/it- https://backstage.io/## Ricordati di iscriverti al gruppo telegramhttps://t.me/gitbar## Supportaci suhttps://www.gitbar.it/support## Paese dei balocchi - https://www.amazon.it/Good-Strategy-Bad-Difference-Matters/dp/0307886239- https://github.com/immobiliare/backstage-plugin-ldap-auth- https://www.waterdrop.it/## Contatti@brainrepo su twitter o via mail a info@gitbar.it.## CreditiLe sigle sono state prodotte da MondoComputazionaleLe musiche da Blan Kytt - RSPNSweet Lullaby by Agnese ValmaggiaMonkeys Spinning Monkeys by Kevin MacLeod

Semtech's LoRa device-to-Cloud platform is a globally adopted long-range, low-power solution for IoT applications, enabling the rapid development and deployment of ultra-low power, cost-efficient, long-range IoT networks, gateways, sensors, module products, and IoT services worldwide. Semtech's LoRa technology provides the communication layer for the LoRaWAN® standard, which the LoRa Alliance® maintains, an open IoT alliance for Low Power Wide Area Network (LPWAN) applications that have been used to deploy IoT networks in over 170 countries. With the proliferation of LoRa devices and the LoRaWAN standard, the LoRa Developer Portal is a place to learn, connect, collaborate, and find resources to help accelerate your LoRa development process. Semtech is a founding member of the LoRa Alliance. Steven Hegenderfer, senior director of developer ecosystems at Semtech, joins me on Tech Talks Daily to discuss Semtech's LoRa Developer Portal. The portal allows developers of all levels to quickly build and test IoT devices connecting with LoRaWan. In addition, I learn how it aims to help developers bring their ideas to life and close the skills gap many companies are facing by offering resources for education and training purposes. This portal comes at a time when building IoT devices and solutions are more complex than ever before, and developers need additional resources to build and test device connectivity efficiently.

We just watched Revolution OS before the show, so we reflect on the audacity of their vision and the new revolution we see brewing.

Paycor's new developer portal speeds data transfer, Lever deploys winter release. And more.

Paycor's new developer portal speeds data transfer, Lever deploys winter release. And more.

In this episode, we look at the skills needed for developing a developer portal. We also talk about our new e-learning course "Creating API documentation and developer portals", and Google's recommendations for the content needed on a developer portal.  We'll post a transcript to the Cherryleaf Blog.  About Cherryleaf: Cherryleaf

In this episode, Milen Dyankov joins me to discuss education and learning at AxonIQ. We speak about the challenges of learning new concepts — such as DDD, CQRS, Event Sourcing, Event-Driven Architecture. Milen discusses some of the tools and platforms he's evolved and improved, including Discuss Platform and AxonIQ's Developer Portal. Stay tuned for part II, where we dive into Axon Academy!  Connect with Milen on LinkedIn and Twitter.  Connect with Sara on LinkedIn and Twitter.  For more information about us visit axoniq.io

Audio version of video on YouTube.  This week: Microsoft Teams App Studio will be depreciated, time to use Developer Portal  Walkthrough – Creating a populated Teams environment with the Microsoft 365 Developer Program Sandbox  Breaking changes to attendance report in Microsoft Graph onlineMeeting API (beta)    Subscribe to all my videos at: https://thoughtstuff.co.uk/video Podcast: https://thoughtstuff.co.uk/itunes, https://thoughtstuff.co.uk/spotify or https://thoughtstuff.co.uk/podcast Blog: https://blog.thoughtstuff.co.uk    

With the Dev Portal Awards 2021 under way, we look at the characteristics of an award-winning developer portal.  Dev Portal Awards 2021 What is your developer portal's KPI score? About Cherryleaf: Cherryleaf

For a while now, we've been looking at ways to import API reference content into MadCap Flare, so that we can use Flare to create a developer portal. Here's the latest update on what we've learnt.  Videos: Importing OpenAPI/Swagger API reference content into MadCap Flare 2021 to create a developer portal Importing API reference documentation into a MadCap Flare project Cherryleaf is a technical writing services and training company based in the United Kingdom. Part of that work involves updating and improving developer portals.   Cherryleaf also offers a Writing API Documentation elearning course that teaches Technical Writers the keys skills of writing and managing documentation for REST APIs. Cherryleaf newsletter To contact Cherryleaf: info@cherryleaf.com

Audio version of video on YouTube.  There’s a new Developer Portal for Microsoft Teams! There’s a new Microsoft Teams Toolkit out for Visual Studio developers New Meeting APIs for Microsoft Teams meetings Microsoft Teams Messaging Extensions now work in Outlook! Developers can now build Microsoft Viva Connection cards Fluid Framework is coming to Microsoft Teams – now in private preview Microsoft is now charging to use Microsoft Graph Data Connect – here’s how much Azure Communication Services adds Recording, Direct Routing & more Windows Terminal 1.9 – now with QUAKE MODE! Subscribe to all my videos at: thoughtstuff.co.uk/video Podcast: thoughtstuff.co.uk/itunes, thoughtstuff.co.uk/spotify or thoughtstuff.co.uk/podcast Blog: blog.thoughtstuff.co.uk  

Theme of the week: How integral is "community" in Developer Relations? Happy New Year! This is our first episode for 2021 and we are joined by a great friend, Leandro Margulis. Community is all about people coming together and working together. But, do you really need to build your own community? We talked about this with Leandro and also about several Developer Relations and community topics: What he loves most in Developer Relations  How integral is "community" in Developer Relations  Tactics to make your community more welcoming - and hence more inclusive Do you need to build a community? Meeting developers where they are The future of Developer Relations Listen to this episode to meet developers where they are and make your community welcoming. Let’s talk Data This is the graph we discuss with Leandro: https://www.devrelx.com/trends?lightbox=comp-kisqz2fe3__item-kisqu8ax_runtime_dataItem-kisqz2ff?utm_source=UTHODM_0307_Description&utm_medium=UTHODM_0307&utm_campaign=UTHODM_0307 (Ranking of reasons for adoption). Trends page now has a new look and fresh graphs! Make sure to check it out.   Leandro Margulis is the VP of Developer Relations at UnifyID. He is an entrepreneurial leader with strong Business Development experience, effective sales and marketing skills used to launch new products and businesses. Leandro sits at the intersection between business and product, thinking creatively about product and partnerships to fulfil the customer's use case. Leandro is the customer's advocate internally and the company's advocate externally. Prior to joining Unify ID, Leandro led Developer Relations at TomTom. In this role, Leandro led a global, multidisciplinary team including Sales, Marketing, Product Marketing and Developer Portal engineers with the mandate to build the developer community around TomTom Maps APIs.

In a special guest episode, we are joined by TomTom’s Head of Developer Portal, Gregory De Jans, and Head of Product Marketing, Louis Debatte-Monroy. We chat about how API’s can create new business models for enterprises and what you might need to consider when marketing to a new community of users and consumers.---The BCG Platinion on Digital Podcast brings you expert discussions on how winning organisations are harnessing new technologies and digital ways of working. Every episode features a topic at the core of BCG Platinion; adoption of emerging technologies, digital design, IT engineering and architecture, Agile and cybersecurity. Subscribe now for the latest perspectives from knowledge leaders in technology and digital transformation .Learn more about BCG Platinion on our Website or LinkedIn

Growing investor and borrower demand along with heightened regulatory pressure often have mortgage lenders backlogged with integration work and operational inefficiency. Freddie Mac is focused on delivering solutions to clients that will increase efficiency and data accuracy, saving them time and money. Learn more about how Freddie Mac is using application programming interfaces (APIs) to speed up and simplify pre-qualifications, simplify decisioning on workout options and create a more efficient borrower experience.

All about change and introducing companies to bring the Developer Experience (DX) and Developer Portals to the forefront. Dev Portal Awards - https://devportalawards.org/Spotify Backstage - https://backstage.io/

YouTube にて先行して配信を始めていた、最新情報を "ながらで" キャッチアップ！ラジオ感覚放送「毎日AWS」 7月より Podcast での配信も開始します！ (※本エピソードは Podcast 配信前に YouTubeで上げたモノになります。) 最新情報を "ながら" でキャッチアップ！ ラジオ感覚放送 「毎日AWS！」 おはようございます、サーバーワークスの加藤です。 今日は 6/25 に出た 6件のアップデートをご紹介。 感想は Twitter にて「#サバワ」をつけて投稿してください！ ■ UPDATE ラインナップ Serverless Developer Portalにユーザー管理を含む改善が追加 Amazon EMR でスポットインスタンスを使う際、 コストと中断を抑えてプロビジョニングすることが可能に AWS CodeBuild が追加のシェル環境をサポート Amazon Rekognitionのカスタムラベルが単一オブジェクトのトレーニングをサポート AWS IAM のサービス上限を AWS Service Quotas で管理可能に Amazon RDS for MySQL がマイナーバージョン5.6.4, 5.7.30をサポート ■ サーバーワークスSNS Twitter / Facebook ■ サーバーワークスブログ サーバーワークスエンジニアブログ

Recently I chatted with Kristof van Tomme, CEO and co-founder of Pronovix, about a topic that's become increasingly relevant in the past several months: how to deal with complex, rapidly evolving landscapes. Specifically, we focus on developer portal strategies that involve finding a balance between constraints and flexibility. Too many constraints reduces your ability to adapt to uncertain changes that might require innovative, unknown solutions. Too much flexibility might not lead to any coherent, overarching story about how to use your APIs in an integrated way toward a business goal.

In this edition of ProgrammableWeb's Developers Rock Podcast, David Berlind, editor in chief of ProgrammableWeb interviews Andrew Lawrence, director of product management at Commerce Cloud at Salesforce to find out more about the new Commerce Cloud developer portal, which, for the first time, allows anonymous developers to come and experiment with 20 different APIs. To see the video version of this interview or to get a full-text transcript of this presentation, go to: https://www.programmableweb.com/news/salesforce-commerce-cloud-exposes-apis-to-public-new-try-you-buy-developer-portal/interview/2020/03/18

The all-new API Management developer portal lets you effortlessly publish your APIs. It's customizable, lightweight, and intuitive. Mike Budzynski joins Scott Hanselman to show how to publish your APIs with the new developer portal in Azure API Management.[0:03:30] - DemoAzure API Management resourcesAzure/api-management-developer-portal (GitHub repo)Azure API Management developer portal overviewTutorial: Implement widgetsAzure API Management overviewCreate a free account (Azure)

The all-new API Management developer portal lets you effortlessly publish your APIs. It's customizable, lightweight, and intuitive. Mike Budzynski joins Scott Hanselman to show how to publish your APIs with the new developer portal in Azure API Management.[0:03:30] - DemoAzure API Management resourcesAzure/api-management-developer-portal (GitHub repo)Azure API Management developer portal overviewTutorial: Implement widgetsAzure API Management overviewCreate a free account (Azure)

The all-new API Management developer portal lets you effortlessly publish your APIs. It's customizable, lightweight, and intuitive. Mike Budzynski joins Scott Hanselman to show how to publish your APIs with the new developer portal in Azure API Management.[0:03:30] - DemoAzure API Management resourcesAzure/api-management-developer-portal (GitHub repo)Azure API Management developer portal overviewTutorial: Implement widgetsAzure API Management overviewCreate a free account (Azure)

The all-new API Management developer portal lets you effortlessly publish your APIs. It's customizable, lightweight, and intuitive. Mike Budzynski joins Scott Hanselman to show how to publish your APIs with the new developer portal in Azure API Management.[0:03:30] - DemoAzure API Management resourcesAzure/api-management-developer-portal (GitHub repo)Azure API Management developer portal overviewTutorial: Implement widgetsAzure API Management overviewCreate a free account (Azure)

The all-new API Management developer portal lets you effortlessly publish your APIs. It's customizable, lightweight, and intuitive. Mike Budzynski joins Scott Hanselman to show how to publish your APIs with the new developer portal in Azure API Management.[0:03:30] - DemoAzure API Management resourcesAzure/api-management-developer-portal (GitHub repo)Azure API Management developer portal overviewTutorial: Implement widgetsAzure API Management overviewCreate a free account (Azure)

Published 2017/03/28 In this interview, we talk to Joris Hensen and Frank Pohlgeers from the Digital Factory of Deutsche Bank. We talk about the intention of Deutsche Bank to help build an ecosystem, by granting fintechs access via their API, but also for non-fintechs. Deutsche Bank is interested in cooperating with startups from fintech, what they call “near-banking” and “beyond banking” and is opening itself up to them. The bank is even working on a partnership program to help start an ecosystem. If you want to know more about the API of Deutsche Bank, you can learn more in the Developer Portal of DB. The interview was conducted by Joern and Gaurav from the startuprad.io team in Frankfurt, inside the Digital Factory of Deutsche Bank. During the interview, we talk about the winners of Deutsche Bank Hackathon API/OPEN. You can find our interviews with three of them here: DWINSFinchildWireAffiliated Links GlobalUSAEuropeGermanyCo-WorkingWeWorkWeWorkWeWorkWeWorkMarketing / SEO / Graphics / Sounds and moreFiverrFiverrFiverrFiverrEmail service?G-SuiteG-SuiteG-SuiteG-SuiteLearn more about our Affiliated Marketing here: https://www.startuprad.io/blog/affiliate-marketing-at-startuprad-io/ © Startuprad.io - All right reserved

In this interview, we talk to Joris Hensen and Frank Pohlgeers from the Digital Factory of Deutsche Bank. We talk about the intention of Deutsche Bank to help build an ecosystem, by granting fintechs access via their API, but also for non-fintechs. Deutsche Bank is interested in cooperating with startups from fintech, what they call “near-banking” and “beyond banking” and is opening itself up to them. The bank is even working on a partnership program to help start an ecosystem. If you want to know more about the API of Deutsche Bank, you can learn more in the Developer Portal of DB. The interview was conducted by Joern and Gaurav from the startuprad.io team in Frankfurt, inside the Digital Factory of Deutsche Bank. During the interview, we talk about the winners of Deutsche Bank Hackathon API/OPEN. You can find our interviews with three of them here: DWINSFinchildWire Folge direkt herunterladen

In this episode, we talk to Stella Crowhurst, Content Strategy Director at ‎Worldpay. We discuss: * How Worldpay reduced complexity in the developer experience by combining multiple properties in a single portal. * How Worldpay uses Lean methods to develop documentation within an Agile development environment.  * The new tool Worldpay is building in-house that allows to display the API documentation, reference and a sandbox all in one page so that developers can access all the information they need on one screen, speeding up the integration process. * The way the technical writers work as an API content team in collaboration with the internal development teams. Links: Stella's article, Getting started with a Dev Portal email: info@cherryleaf.com Become a better technical communicator by subscribing to the Cherryleaf newsletter www.cherryleaf.com   Sponsored : MadWorld Europe 2018 Conference MadCap Software product overview

Bill will be discussing and demonstrating the features Azure API Management. Looking at the Publisher/Azure Portal, Developer Portal and demonstrating API import and the power of the API Management Policies. Bill will also discuss the different usage scenarios and benefits of Azure API Management of both Web Application and Hybrid Integration.

In this week's podcast, Patrick Wilson explains how to use the new Service Portal, available in Helsinki. This episode covers: - No code, low code, and pro code for all levels of users - Customizing widgets in the portal - Debugging Service Portal - Security in the portal For more information on Service Portal, see: What’s in a Service Portal? How to communicate between widgets in Service Portal Adventures in Service Portaling: Introduction and Resources Adventures in Service Portaling: The Form Widget Product Documentation: Service Portal  Your feedback helps us better serve you! Did you find this podcast helpful? Leave us a comment to tell us why or why not. To catch clips behind the scenes with our podcast guests, and find out what topics we'll be covering next before they are posted, follow @NOWsupport on Twitter. You can also search Twitter using the hashtag#SNtechbytes for all previous podcasts, video clips and pictures.

The developer site recently introduced a feature where instances will hibernate, or "sleep" when they go unused after a couple hours. In this podcast, Bryan Barnard​ and Jack Nguy​ discuss what this means for you and how to "wake up" your instance. This episode covers: - Personal Development Instances (or PDIs) as the on-ramp to ServiceNow - Differences between the developer program and the technology partner program - Overview of hibernation - Hibernation vs instance reclamation - Troubleshooting issues - Instance versions and PDIs - Plugins and integrations for your PDI For more information on hibernation and the developer site, see: Techbytes Episode 9: ServiceNow Developers Site ServiceNow Developers Site Developer Community ServiceNow Developer Site Walkthrough - YouTube Your feedback helps us better serve you! Did you find this podcast helpful? Leave us a comment to tell us why or why not. To catch clips behind the scenes with our podcast guests, and find out what topics we'll be covering next before they are posted, follow @NOWsupport on Twitter. You can also search Twitter using the hashtag #SNtechbytes for all previous podcasts, video clips and pictures.

Director of Integration Services Daniel Berry and Sales Engineer Jason Wells from the Nuix Field Engineering team sit down to talk about the Nuix Developer Portal, an online resource for customers and developers using Nuix to share ideas and ask questions. They talk about where the idea for the award-winning portal came from, how it helps Nuix to deliver solutions its customers need, and their vision for the portal over the next few years.

Panel Andrew Madsen (twitter github blog) Pete Hodgson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Ben Scheirman (twitter github blog NSSreencast) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:33 - The Apple Developer Portal 01:57 - When the portal goes down 05:35 - What the Portal Does iBooks System Status 07:20 - Certificates and Provisioning Profiles Wildcard Certificate nomad cupertino shenzhen venice 17:50 - Managing the Device List 21:45 - Clients and Developer Accounts 23:00 - NDA 27:04 - Submitting Apps to the App Store 29:04 - iTunes Connect 34:24 - Rejecting Apps 37:46 - Apps on Particular Devices Version Requirements 44:05 - Entitlements 44:44 - TSIs Picks FontAwesome-for-iOS (Rod) When to use -retainCount? (Andrew) Strange Loop (Pete) Boxen (Pete) Homebrew (Pete) The Changelog (Pete) Brian Gorby - AppResigner: Easily re-sign iOS apps (Ben) Apple - Support - iPhone - Enterprise (Ben) Average App Store Review Times (Ben) Brian Stevens / Data Porters (Chuck) Canvas by Instructure (Chuck) Wistia (Chuck) Next Week Performance Tuning with Brandon Alexander Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 16 of the iPhreaks Show! This week on our panel, we have Andrew Madsen. ANDREW: Hi from Salt Lake City! CHUCK: Pete Hodgson. PETE: Hello from San Francisco where BART is not striking here. BEN: [Chuckles] CHUCK: Where what is not striking? BEN: BART. CHUCK: BART. PETE: Bay Area Rapid Transit. CHUCK: Rod! ROD: Hello from Salt Lake City! CHUCK: And we also have Ben Scheirman. BEN: Hello from Houston where it's 180 degrees! [Laughter] CHUCK: I'm Charles Max Wood from DevChat.tv. Real quickly, one of the reasons that I do this show is so that I can get work. So if you need backend work for your iPhone application and you're interested in using Ruby on Rails, I am available for hire! Alright, well let's get to the show! This week, we were talking about and having a discussion on the "Apple Developer Portal", when it's working. [Chuckles] ANDREW: Which is, sort of mostly right now. BEN: Yeah. We'll be back soon [laughs]. CHUCK: Yup. PETE: Except not soon. [Laughter] PETE: For some definition to see. CHUCK: Yeah. ANDREW: Oh, man! BEN: Yeah. They have a very loose definition of soon, I think. PETE: [Chuckles] BEN: Do we want to start off by just talking about what happened there? I don't know if anybody has any like behind the scenes info on the portal being down, but from what I heard, they detected some sort of hack attempt. And then shortly there after, this, I think he was an Israeli hacker, or I shouldn't say hacker, security researcher, came out and said -- CHUCK: [Laughs] BEN: "I successfully exploited this thing, and I told you about it and filed a radar. I just wanted to see how deep it went," so he pulled out, I don't remember how many users' contact info from the Dev Portal, and he posted a little screencast on the type of data he got and the level. I don't know if that -- they seem to be related because it was like around the exact same time.

Panel Andrew Madsen (twitter github blog) Pete Hodgson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Ben Scheirman (twitter github blog NSSreencast) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:33 - The Apple Developer Portal 01:57 - When the portal goes down 05:35 - What the Portal Does iBooks System Status 07:20 - Certificates and Provisioning Profiles Wildcard Certificate nomad cupertino shenzhen venice 17:50 - Managing the Device List 21:45 - Clients and Developer Accounts 23:00 - NDA 27:04 - Submitting Apps to the App Store 29:04 - iTunes Connect 34:24 - Rejecting Apps 37:46 - Apps on Particular Devices Version Requirements 44:05 - Entitlements 44:44 - TSIs Picks FontAwesome-for-iOS (Rod) When to use -retainCount? (Andrew) Strange Loop (Pete) Boxen (Pete) Homebrew (Pete) The Changelog (Pete) Brian Gorby - AppResigner: Easily re-sign iOS apps (Ben) Apple - Support - iPhone - Enterprise (Ben) Average App Store Review Times (Ben) Brian Stevens / Data Porters (Chuck) Canvas by Instructure (Chuck) Wistia (Chuck) Next Week Performance Tuning with Brandon Alexander Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 16 of the iPhreaks Show! This week on our panel, we have Andrew Madsen. ANDREW: Hi from Salt Lake City! CHUCK: Pete Hodgson. PETE: Hello from San Francisco where BART is not striking here. BEN: [Chuckles] CHUCK: Where what is not striking? BEN: BART. CHUCK: BART. PETE: Bay Area Rapid Transit. CHUCK: Rod! ROD: Hello from Salt Lake City! CHUCK: And we also have Ben Scheirman. BEN: Hello from Houston where it's 180 degrees! [Laughter] CHUCK: I'm Charles Max Wood from DevChat.tv. Real quickly, one of the reasons that I do this show is so that I can get work. So if you need backend work for your iPhone application and you're interested in using Ruby on Rails, I am available for hire! Alright, well let's get to the show! This week, we were talking about and having a discussion on the "Apple Developer Portal", when it's working. [Chuckles] ANDREW: Which is, sort of mostly right now. BEN: Yeah. We'll be back soon [laughs]. CHUCK: Yup. PETE: Except not soon. [Laughter] PETE: For some definition to see. CHUCK: Yeah. ANDREW: Oh, man! BEN: Yeah. They have a very loose definition of soon, I think. PETE: [Chuckles] BEN: Do we want to start off by just talking about what happened there? I don't know if anybody has any like behind the scenes info on the portal being down, but from what I heard, they detected some sort of hack attempt. And then shortly there after, this, I think he was an Israeli hacker, or I shouldn't say hacker, security researcher, came out and said -- CHUCK: [Laughs] BEN: "I successfully exploited this thing, and I told you about it and filed a radar. I just wanted to see how deep it went," so he pulled out, I don't remember how many users' contact info from the Dev Portal, and he posted a little screencast on the type of data he got and the level. I don't know if that -- they seem to be related because it was like around the exact same time.

Friday, July 26, 2013 - Grab-bag episode. The Developer Portal outage. Deciding the kind of business you want to run. Leverging your past solutions to new problems. Staying with it when you get stuck. Recommending the Çingleton Symposium. Dev Portal Status Honest In-App Purchases Çingleton Symposium 3