Last month, the SmartBear team had the opportunity to sponsor and attend the 2018 Glue Developer Conference (GlueCon) in Broomfield, Colorado.
GlueCon is a developer conference focused on the tools and platforms that are changing the technology landscape – including: Serverless Architectures, Containers, Microservices, APIs, DevOps, Mobile, Analytics, Performance Monitoring, and Blockchain Applications.
In addition to showcasing SmartBear API tools, like SwaggerHub for API design and documentation, SoapUI Pro for testing, ServiceV for service virtualization, and AlertSite for synthetic API monitoring, we also had the chance to participate in presentations and workshops at the event.
I caught up with Keshav Vasudevan, Product Marketing Manager, Swagger at SmartBear at the event, to get his thoughts on the show, and see what insights he could share from the two-day conference.
Watch the full interview and read the recap below:
Thank you for joining me to share some lessons from GlueCon 2018. What have been some of the takeaways from some of the sessions you've attended and people you’ve met at the show?
What’s great about this event is that there is a good mix of practitioners, who are in the weeds, building APIs and building software. And then you also have the people who are guiding the software development workflow. And that mix is well represented in the talks at the event.
One session that really stood out to me was the Day One keynote by Adrian Cockcroft from AWS on the concept of Chaos Architecture. Chaos isn’t something most people think a lot about because it’s viewed as some inevitable behavior that is difficult to plan for. But if you’re on a team that is developing applications for, say an industry like aviation or healthcare, there are serious implications of your software’s performance on the safety of your users.
So even if you can’t necessarily predict chaos, you should have the right processes and training to make sure that you can account for it. Cockcroft also mentioned that you should not have a single point of entry. And that’s why distributed services in general, are becoming so much more important.
Another talk was by Lisa Kamm and Max Whitney on the software development lifecycle, titled: Systems Development Life Cycle (SDLC) Meets the Organizational Development Life Cycle. They talked about how you shouldn’t just be making decisions about your software lifecycle based on best practices, or an article you read online. You really need to understand your organization’s culture and the risks that come with it – whether those risks are reputational, financial, or specifically related to your software. You have to balance those risks with your goals and objectives, and plan accordingly.
And finally, I’d like to mention a talk from James Higginbotham of LaunchAny. James’s talk, Is REST Still Relevant, provided an interesting take on how we, as an industry, are constantly trying to reinvent the wheel. And that there are always all sorts of arguments about different protocols or whether on certain description formats will support different things, when the reality is that your underlying HTTP protocols already have the necessary systems in place.
A lot of the challenges we keep wanted to revisit have already been solved, so the discussions should be more focused on: "What is my final business outcome? What is the end result of my API programs? And what description formats or what architecture should I be using based on that?” Some of your APIs could be SOAP, some of them could be GraphQL, some of them could be GRPC, and some of them could be REST. It's totally up to you, depending on the business outcome you’re looking for, and what your end consumer needs.
GlueCon really feels like it’s a living and breathing case study in action. People from different companies, from startups companies at scale are here sharing what they’re doing and the challenges they’re facing. Could you provide some of examples of the companies you’ve heard from and the lessons they’ve shared.
Vinu Charanya and Fabio Rojas of Twitter shared some interesting insights on ownership. Twitter is used by millions of users, and justifiably, they have a lot of services that help support their growing business.
They spoke on how it becomes hard to track ownership of all these services. What is the lifecycle of the service? What is the impact the service has on the business? And how do you easily discover all these services as well? Twitter had an interesting problem, especially given that there's always new employees coming in and people moving from one team to the next. It becomes hard to track the right person who's in charge of that service.
They built this interesting system called Kite to track ownership and measure impact of these services based on the ROI. Every service you build can somehow be translated to revenue or cost saved. And this really allows people to take ownership of their services, and also leads to them building services that can be connected to some sort of tangible business outcome by maximizing the ROI or the quantitative revenue impact.
I understand you are also taking the stage at GlueCon. What was the topic of your talk, and why did you think this was an important topic to cover?
My session is titled: How Serverless and the OpenAPI Specification Can Accelerate Your API Development.
After speaking to many people in the past and at this event, I’ve learned that most teams are still following more of a “code first” approach to using the OpenAPI Specification (OAS). Specifications like the OpenAPI are important for both business and technological processes, and my talk is really focused on why you should be thinking about the outcomes you want, before you start building an API, and adopt a design-first approach.
Serverless architecture is an important part of this as well, because you can accelerate your entire API development process by using these out of box functions and tie them with your API development processes, using the OpenAPI Specification.
I know SmartBear also announced a major update related to the OpenAPI Specification in the new Swagger Inspector tool, which has gotten some attention at the SmartBear booth. Could you talk a bit about the new functionality?
Swagger Inspector is a simple, free browser-based tool, which any individual developer or team can use to test out their different API endpoints, and see what the API endpoint does. Swagger Inspector also integrates with the SwaggerHub platform, and helps you make your APIs more consumable by generating an OpenAPI Specification, based on the API calls. In the most recent announcement, we added full support for the latest version of the spec, OpenAPI 3.0.
Let’s say for example, you want to test your API that's defined with OpenAPI 3.0. You can just insert the resource path or the URL which has the API definition, and Inspector will automatically parse that and show you all the different methods and resources associated with that API. You can quickly explore that API and test various endpoints associated with that API.
Another major update is the ability to generate OpenAPI 3.0 definitions from APIs that do not already have a definition in place. As I said, many teams are following the “code first” approach, and implementing the API before writing a spec. With Swagger Inspector, you can insert an endpoint, and with a click of a button, generate your entire API definition. This will open a world of possibilities, including the ability to build out your API documentation, and generate client SDKs or server stubs within the SwaggerHub platform.
We’ve gotten some great feedback so far, and we’re excited to see what developers think of the latest update.
Awesome, well, that's great to hear. Thanks so much for sharing some of your takeaways!