rss-bridge 2026-02-27T09:19:00+00:00

Presentation: Platforms for Secure API Connectivity With Architecture as Code

Jim Gough discusses the transition from accidental architect to API program leader, explaining how to manage the complexity of secure API connectivity. He shares the Common Architecture Language Model (CALM), a framework designed to bridge the developer-security gap. By leveraging architecture patterns, engineering leaders can move from six-month review cycles to two-hour automated deployments. By Jim Gough

InfoQ Homepage

Presentations

Platforms for Secure API Connectivity With Architecture as Code

Architecture & Design

Platforms for Secure API Connectivity With Architecture as Code

Reading list

49:10

Summary

Bio

James Gough is a Distinguished Engineer and API Platform Lead Architect at Morgan Stanley, where he works on API strategy, security, and developer experience. A Java Champion, author, and conference speaker, Jim has contributed to the Java Community Process, co-authored Mastering API Architecture and Optimizing Cloud Native Java (O’Reilly), and leads open-source initiatives like FINOS.

About the conference

Software is changing the world. QCon London empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Transcript

Jim Gough: Let's go into chatting about what we're here to do, which is talk about APIs. Specifically, I want to walk through some experiences that I've had working at Morgan Stanley while thinking about things like evolving API connectivity over time to thinking about secure design approaches from the outset and how we work with developers on that. Looking at what I call architecture patterns, and this is a new idea, so I'll walk you through that as well. We're going to do some live demos. Then I'll talk about a potential workflow before we wrap up.

Who Am I?

I'm Jim. I work at Morgan Stanley. I'm a Java champion, so I've done lots of stuff with open source. If you've seen JSR 310, the Date, Time API in Java was heavily involved in that. I've written a couple books. I'm also the developer and architect of Morgan Stanley's API program. Why do I say developer and architect? It's deliberately ambiguous. The reason for this is because when I started, I was the only developer of Morgan Stanley's API program, and I've become a bit of an accidental architect. As complexity has increased, as we have offered more services across the organization, I've become more responsible for more things, and that's what I want to talk about now.

The Complexity of API Connectivity

The complexity of API connectivity. I think building APIs is so simple. Caveat, it's not. Actually, working with tools with no security, you've got a consumer and an API service, you can pretty much get that up and running on your laptop in two or three minutes with some modern frameworks. Then, authentication and authorization comes in. You need a way to model this. If your users are outside an organization, or they need to cross trust boundaries, then it becomes a really big deal, and you have to start thinking about how you're going to make that consistent, regardless of what the API services look like in the background.

The first thing you're probably going to do is say, API management, there's a tool that does that for us. This introduces some complexity. As a user, if you're an operator, you have to go in, potentially set up some policies. You've got to be very careful what policies you do set up there. API management can do lots of things, which is great, until you then maybe want to move it somewhere else, and then it's maybe not so great. This is pretty much the beginning of any journey. You can be profitable by just getting this model correct. It's quite simple.

Typically, as you want to scale and grow, you're going to add in some element of automated deployments. Previously going into that user interface and configuring things that seemed easy at the time now means that you have to learn a whole series of APIs, APIs that will probably not be available to you in your dev environment. You might use stuff like WireMock, to mock out these dependencies, that makes things a little bit more complex. We have to manage the deployment of the API service in the background, and typically you need to make sure these things are coordinated and released at the same time to have zero downtime and also zero impact in terms of the specification.

The other thing that will probably happen along the way is that typically you don't want your API management doing things like service discovery and combination of services. You're probably going to end up deploying some element of gateway, whether it's security-related or possibly just even microservices-based architectures to give you routing to different endpoints downstream. We're going up on that complexity scale quite quickly. There's then these other things that get in the way, non-functional requirements. These are super important. Thinking about things like security from the outset. I'm going to talk a little bit more about security as we go through the presentation. What's your performance like?

Often, in terms of performance, we think about what is acceptable, think about service-level agreements. What I found with working with this is usually my users internally are misaligned with what performance characteristics of REST APIs will look like. Even just being clear in terms of communicating that is important. We also need to look at things like the availability. If we were to lose given infrastructure, can we still operate in a way that still serves our business? Observability is absolutely critical. Actually, I was looking at some observability traces to try figure out what was going wrong with something in production. It was very quick to narrow down. Then you want to have things like audit logs. Audit logs to make sure that you're compliant with various things, that you can see what has happened in your system.

General compliance, that depends on where you operate and your operating environment as to what you'd want to capture here. I'll give some hints around that as well. The cost is important. It's very easy to spin things up and maybe forget that they're running and then suddenly you've got a massive bill at the end of the year. Ultimately, you want to be able to grow and maintain this as your journey progresses.

These typically non-functional requirements actually become critical operating requirements. For me and in the work that I do, if I don't have all of these things, I can't actually run a successful API program because it's going to be constantly doing maintenance hygiene, other things that are required to then get to the point of what looks like good. My complexity goes up again. There's a lot more things for us to think about. The question I would ask is this idea of we'll just left shift it. The thing that happens is there is a gap between developers and infrastructure. If you shift too far left and say, developers, here are these things that you can do to roll out your API, and we can have things that are abstracted for you that make things easy.

Then they go, "I don't really know what I'm doing, or this is too much YAML, too much infrastructure as code", you've shifted too far left without support. As a developer, I quite like to get all the shiny tools, but then sometimes operating them is a bit more complex than it could be. Then we also move on to this term, undifferentiated heavy lifting. If you spend a lot of your time working with infrastructure and plumbing, it distracts from what you're trying to do, which is, in our cases, delivering products or impacting the user in a positive way. This developer and infrastructure gap is something else that we need to navigate as we go through building our systems.

[...]

*Original source*