You can listen to the podcast and read the show notes here.
Michael: Welcome back to the show. I'm here with Brian Sappey. I hope I’m saying your name that right there Brian. It looks kind of vaguely foreign even though I know you're American.
Brian: yes Sappey
Michael: Sappey, all right. And we're gonna be talking about how he's implemented Adobe's A.P.I. manager with swagger ColdFusion A.P.I. And we'll look at what the A.P.I. manager is and why you should be using it. And what swagger is and how you might use that. And how they migrated from using Layer seven for all these stuff, and some of the big cost savings they had and a whole bunch of automation they're doing in that ColdFusion development using this. So welcome Brian.
Brian: Thank you, appreciate it. Thank you giving me the time.
Michael: Oh! You're so welcome. Thanks for staying up late to do this. I know it's after hours for you. And I know you're off to CF Summit in a few days. So glad you were able to fit this interview in. So tell us what is the… not everyone's use the A.P.I. manager in ColdFusion. Tell us what that is and why we should be using it.
Brian: Adobe a few years ago, they started developing their own internal A.P.I. manager platform. And ideally really what it is it's a management tool that allows you to integrate all the elements of development and managing all the processes and A.P.I.s. And be able to put into a centralized location that allows you to really manage your REST and your SOAP API’s and grow the business. And you know I actually have some control on data and analytics all the things that are really important to having a successful [inaudible] [01:34] architecture plan. The idea of it to go to this was a fairly significant one for the company that I work for. You know A.P.I.s have become a very popular family amongst all the technologies and all [inaudible].
And it's obviously the way things have been moving for some time, and they're continually move that direction. So in order to be a real player in it, and to have an enterprise type environment to be able to manage a business and then also the development side, you have to have a platform. And when we saw that Adobe had been putting quite a bit of effort into developing this platform, we thought it might be a good opportunity to take a look at helping to further not only the ColdFusion language, but also a product that Adobe was putting together especially since the incentive was there since we were already an enterprise customer looking for Adobe ColdFusion.
The challenge of course was that we already had Layer seven which is formally Layer seven, but it is now a CA product; there A.P.I. manager tool. So the process of going through all that pain, and labor pains, and sweat equity of implementing that product and then even thinking about going down this road was a big decision. Especially the amount of time, and money, and effort; everything else that have been put in. And interestingly enough, the A.P.I. manager by then was not built on ColdFusion. It's actually built on Java ana Angular, but it ships with ColdFusion. So the opportunity there was a big cost savings for us and we already had been paying for a ColdFusion license the opportunity to scale back and not have to have a half million dollar bill to use the CA product was quite an incentive.
Michael: wow!
Brian: So that's the main… one of the main driving forces of how we got here and one of things that put everything in motion and but it's been quite a journey. But the process of moving over has been met with a lot of help with Adobe and a lot of hands on and to say a tremendous amount of support from the Adobe team. So it's been very successful to date.
Michael: Wow! So you said the CA product cost would have cost half a million a year to use?
Brian: Yeah, all implementations are different that's by no means are authoritative number for each client or each company that may be using it. But the particular set up that we had done with in order to facilitate our needs as far as the business goes. In the end, all the groups that were going to be consuming it. It was about a 400,000 a year bill. So the savings alone I mean you know the Adobe A.P.I. managers of no cost what the enterprise shipped version of ColdFusion. So we went to 2016. It was just a no brainer and it was a piece of software that we literally had to really empty up no money for in order to try to implement. So the cost savings over the last couple years have been tremendous for the company.
Michael: Wow! They should've given you a raise for making this happen man.
Brian: I second that decision.
Michael: What version of ColdFusion are you guys running then?
Brian: We're running 2016. And per planning to upgrade here. I think the new versions are actually going to be released here this week. I believe that's the plan. I think Thursdays that’s the early release. But they've had the Adobe A.P.I. manager now for some time. And the beauty of it is it actually… you don't have to run it with ColdFusion right. So it's ships with it but there is not a requirement to be running ColdFusion. So it also helps with the licensing and a number of other opportunities that you have there where you're not so restricted. But being as a premier client of Adobe's and we've been with them for a long time and we've been with ColdFusion for a very long time.
It's been as long as I've been in the company. 18 years now I think on going, 19 years I've been using ColdFusion by market America. It's been part of a staple of all the developing application. So the opportunity to pair up with them on a venture like this was really exciting to us, and the product has proven itself time and time again since we've been in production.
Michael: And you’re the application’s architect there; Market America. So were you the guy who basically figured out how to solve this problem, or?
Brian: Yeah, definitely. The whole reason we found out… the company found out about is when I was at the ColdFusion conference two years ago. And they had a booth set up. The Adobe team had their table set up and you know I was just walking by and started asking a couple questions about some of the product changes from the new product releases, the roadmap, everything else. And that's when the Adobe team in particular Rakshith has been a great partner, an ally in this process for us product manager over there in Adobe for ColdFusion.
He introduced us to this new software and we went through a couple of demos and you know one thing that was it's been a initiative of mine since I saw it up so I saw there was a lot of great opportunity. They had really simplified the challenges that we have a Layer seven. They really made it easy. It's a very intuitive piece of software. It really allows business owners to get involved not just technical folks. So they did it right. They really vetted all different types of you know, different platforms; Apogee, Layer seven. They looked at all these different A.P.I. management tools and they were able to… they basically extracted what they thought was most important.
And they really simplified what an A.P.I. manager is and which is a proxy and a way to perform some authentication and some analytics. And really that's the root of what we wanted, and they nailed it. And when we saw that demo, we knew that there would probably be some challenges definitely some bugs. It was brand new software, but we were willing to commit to work through that. And when I brought it back to the management at MArket America, they were thrilled with the product. They saw a lot of opportunity and I think they saw the cost savings, and I was given the go to begin to run with this product.
Michael: That's great and it’s great that Rakshith was able to help you with that. I had him on the podcast a few weeks ago and he's a really knowledgeable guy, excited about the ColdFusion 2018 roadmaps so.
Brian: Yeah, he’s a wonderful guy. He's been a great partner for us some just countless amount of going on the phone at all hours of the night, and getting his development team, and really making the progress. We believe in it, he believes in it. It's really good to see Adobe taking a lot of pride in products and building out their engineering team and really making a commitment. And it makes us feel better I mean we’re a large enterprise shop. And if we see that kind of commitment, it allows us to easier make these decisions to jump on board with their ventures.
It helps when you have the engineering team incredibly involved and willing to make changes, and willing to adapt and grow. And we want to see them get in a force that, we want to stay this product review, we’ll like to see it become an enterprise success amongst other organizations. And if we can help make that happen, it's a benefit for us. We saw it as a win-win and it's just been actually a wonderful experience. And I felt like it's really brought us closer to ColdFusion and brought us closer to the engineering team or at Adobe.
Michael: That's a great success story there. I mean what would it take to get forest at a topical ColdFusion with this kind of enterprise level stuff?
Brian: Ten clients from what I understand. Once they hit the ten client mark then it will be picked up and forced to will perform a white paper in case study on it, and I would love to see it get there. I think the product has a fighting chance. I think that if more ColdFusion shops were to take a look at it, I think they would see the successes that we have. And I think they would be able to run with it, and I really do believe that this will continue… can grow and I believe it's more than capable of an enterprise level. And I have the stats to back it up and the performance of the tool; everything with the whole management suite. And some ways it has completely destroyed Layer seven even on performance latency it has far exceeded the performance of that product.
Michael: Wow! Well it's got to be at least ten people using this. I mean there's hundreds of thousands of sites using ColdFusion, so you've got to figure out maybe. I mean if someone out there is using the A.P.I. manager and ColdFusion with would you like them to contact you or?
Brian: Absolutely and you know if there's any challenges they run into We've been betting this for two years I would love for them to reach out to me. I'd be more than happy to give them any kind of direction. And I can lead them down the path that we've gone in definitely we've been into the pitfalls, we've made the mistakes, and no reason for someone else to suffer those same currents as just the development process or migration process. But I feel like we understand the product, we know what it's capable of, we know where to push it, we know how to implement it, and we have long term plans with it our roadmap is probably just as extensive as Adobe's with what we envision with this project. We've made a number of requests.
I think we've had 40 different changes over the two years of the engineering team of Adobe has helped us with. And I think if the ColdFusion community would just understand what they have available to them, and they actually just took a chance at looking at this, I think they would see that one time it would simplify their lives especially if they're trying to increase their SOA, their API [inaudible] [10:34]. You know they're really serious about getting into REST and even if they're still using SOAP, there's a lot of advantages.
And I have a couple of excellent cases of code that we have say a tremendous amount of time using even the SOAP generator, SOAP to REST generator that we currently use in production today. I have nothing but accolades to talk about some of the ways it is only save us time and money, but has made developers lives much easier. And if the Adobe community that's using ColdFusion if they would just understand it the tool that they have available to all my think it would become a very popular tool in a short amount of time.
Michael: What are some of the ways this is safe you and your other developers’ time, Brian?
Brian: Great example would be one particular… You know we're an e-commerce shop and we deal with a lot of shipping vendors and they typically are a bit slow with updating their A.P.I. architecture. And particular they still… they rely on a lot of SOAP, and it can be a challenge. You know SOAP is a very time consuming. A.P.I. to build and to construct, and deploy, and test. It's a very verbose. And I understand it had some advantages on security back when it was really popular. But obviously, REST is the much preferred transfer you know type of A.P.I. to build these days to make things easier. But one particular tool that the Adobe A.P.I. manager offers is a SOAP to REST wsdl generator.
You're able to take a wsdl and you're able to directly put it into the interface of the A.P.I. manager, and it will generate all the REST endpoints needed in order to make those A.P.I. calls. And we did it for a partner that we use for shipping, and we generated I think it was probably about 50 REST endpoints in less than two seconds after dropping a wsdl in. And it was so successful that the development team saved I would have to estimate maybe a month to two months of development time of not having to build these complicated SOAP A.P.I.s with all these multiple calls and books. We were able to generate these rest endpoints in less than two seconds.
And late within five minutes, we are making test A.P.I. calls through the manager over to this vendor. I think the most important thing that I want to touch on with that was at the vendor came back to us and had mentioned that they were starting to migrate over to REST endpoints it was still in beta version no and we tried a couple of them and they actually did it work and we had pushback to all of them know they… So they were still struggling with trying to figure it out. But literally because of this A.P.I. manager tool, we were able to take SOAP. A SOAP wsdl, generate REST endpoints, and be in production within weeks versus months of development.
So that's just one fantastic case of one of the features that’s rich. I know Layer seven doesn't even offer that. A lot of the A.P.I. managers at the market don't offer that. This is worth its weight in gold to me. You know the amount of time we saved and just the fact that it worked, it was extremely smooth and we were out of the gate running within weeks.
Michael: And so you use this when you're consuming other people's API’s. Do you also use it when you're creating your own A.P.I.s there or?
Brian: Absolutely, we have a company's been going in some different directions with APIs over the years. But one thing that we have really committed ourselves in that you know we consume the same things that we build. So if we're going to build an A.P.I. we're going to put it in API manager, it has to be treated like an A.P.I. for use in a third party it goes to the A.P.I. manager. The analytics that approves to give you the tracking, the tracing, the debugging, the usage, the S.O.A.s; all that can be centralized in one location. So we're not running around to 50 different files or trying to figure out who owns what. This is all centralized, so it allows the business to manage the API’s, but also the developers to easily find what they need.
It's like having a blueprint at your fingertips and allows you to quickly get in there, figure out if something already exists, if something needs to be modified. It allows versioning, you can try the A.P.I.s directly from the tool, and it also gives you that security layer if needed. And so anything that we build at Market America Shop.com, it goes in that A.P.I. manager and that is how we consume it whether it's internal or external.
Michael: So, I'm curious about the analytics you see. You can see how many A.P.I. calls being made, or how long they take, or if something’s slowing up or.
Brian: Yeah, it's feature rich. The analytics dashboards actually very, very interesting the way they went. You know they're using [inaudible] [15:01] and elastic search. So they have this beautiful interface, and it's extremely powerful. It records just about everything you could ever want to know other than the request and response which another feature that we've really push Adobe on and they delivered. So we have the ability to turn on request and response logging on every single end point. But the thing that I really like about Adobe what they've gone the extra mile on my opinion was that they've done everything at a point level, but also resource level where most of the tools you know you can go on you can flip on logging.
But this actually allows me to pick a resource or many resources inside of an A.P.I. collection and I can start to log the response and the request. And I can turn that on and turn it off as a developer. So I don't have to have a special permissions, I don't have to go and restart anything. If I want to know what or how A.P.I. is performing, what's coming in, what's going out, I can see that very easily visually. But then I can also start to run analytics on how my A.P.I. is performing. I can see response time, I can see the HTTP status codes being returned, I can start to filter that data. It’s very intuitive so I can extract, I can pull, I can monitor. But I really get insight into how it's performed.
It's not just I’m gonna push out into production and hope it works. And I won't know anything about it until somebody complains and says there's a problem. All that's built into the manager. And I get those analytics in real time within five seconds. I can have a dashboard that's continually refreshing and just watching the payloads as they come in. So it has been extremely helpful in trying to debug as you know A.P.I.s can be a real challenge to the bug in they dig into and get the analytics. But what the tool allows me to drill in effort with say and get right and get what I need and really focus in on a problem. It helps me really to debug, and it helps me make changes quickly, and get go back out to production if need be.
Michael: Tell us a bit more, for the people who haven't done much A.P.I. development. What are some of the challenges if you weren’t using this tool with debugging?
Brian: Well I think the biggest challenges you know and environment that I work in it's we for P.C.I. reasons. We just don't have production access. We have dev access and then even on a staging level, we have these different environments that we have to push code into, and makes it a bit of a challenge. If you start to have production issues in your code with trying to really lock the problem down. So especially with API’s you're dealing with you know no kind of a U.I. replay or any kind of a logging from that standpoint on trying to track down an error on a user click. This is literally data in, data out. So it's not necessarily an easy thing to track down if you can't see the data, and that's always been a challenge. And then also performance too.
You wanna make sure that it's performing well there might be time outs on the third party side or the consumer side. So because you have this tool, it really allows you to drill down to see the A.P.I.s come in. So the A.P.I.’s that are being called, you can literally see how well it's performing. You can see what kind of status code you're getting back. And that's all key in trying to debug issues. And here's a good example for you. We had another third party that we dealt with or that we currently deal with and they're part of our checkout process.
And that third party, it was a number of A.P.I. calls has five A.P.I. calls all our five A.P.I. that we have generate. Two of those A.P.I. are actually web hooks so they were responses post-processing at some point. We had them into that. So we actually put the web hooks in the A.P.I. manager which has been really helpful because we had a number of problems on production. But we were able to isolate them as being a culprit or not by looking at the logs and the analytics. And we do actually see that the calls are working and we're able to take them out of the rotation of a possible problem and check out.
So seeing even things like this where we would have wasted time in the past, we're trying to nail everything down and really have kind of a trace to follow the entire call, the entire stack. It eliminates that problem because it allows you to drill in very quickly and rule out or isolate problems as they occur rather than trying to work one day or two day old data. It almost allows you to have that kind of wide debugging capability without interfering with code or having to do a deployment.
Michael: Now I notice there’s a sandbox feature in the Adobe A.P.I. manager. Did you guys used that at all or?
Brian: So interesting enough we… sometimes we can get very creative. We saw some potentials here for a sandbox. One of the things I will commend Adobe on is that they give you the ability to provide multiple end points. So if you know we're clustered so we don't run into some of the challenges here and some of the features that are baked in might not necessarily apply to us. But one of the advantages that we are able to use because the licensing is so that we're an enterprise shop, and it doesn't require a ColdFusion license to run this the A.P.I. manager, we were able to spend up an entire collection of boxes that literally we treat as a sandbox. And what does that mean?
Well we're in a lockdown environment; our development environment, or stage environment are fully locked down from the outside world for security reasons. But every once in a while will deal with a third party or there's something that we don't want to necessarily push out into production that we need to expose for business needs to a third party that's been approved. Because of the fact that the Adobe A.P.I. manager has the ability to spin up and instance and actually provide different endpoints, we can create an A.P.I. and the A.P.I. manager, and open it up to dev code or staging coded at any point for any provider.
So using oauth; which is one of the security features built into the A.P.I. manager, we're able to open up small little access to different A.P.I.s and our development or stage environment without having to open up holes in the firewall or punching holes in the firewall or open up special permissions or going through a very painful screenshots certification test for third parties. And just recently, we had a contest here for the local colleges too; an A.P.I. contest. It was a reach out to the community here to try to build some relationships with some of the universities here in Greensboro North Carolina. And we had a very, very unique situation that we…
We had some A.P.I.s that we needed to expose, but we necessarily didn't want them to go all the way to production. So we were able to create an instance of these A.P.I. as an A.P.I. manager, and allow the sandbox to point to any environment we want. So we are able to point them directly Devan lock them down, so they literally couldn't have access to any other A.P.I. They were able to give them a partner type relationship and an API manager and we are going to lock him down that way and it was pretty very successful. In fact, the contest ended today I believe and we had zero issues with the API manager was great. We can monitor the traffic, see who participated, get the analytics and see. You know we kind of had insight before the contest even ended on who was doing what.
Michael: That's really cool and from what I'm understanding of this, you can even have like a fell over server. So if the A.P.I. you’re calling isn't working like you saying it's going out of web service, so it might not be available, it could even fail over to get something to keep the thing.
Brian: That's correct yeah. We can set it up the way it's set up. We can provide multiple fail over URLs which is a really handy feature. In fact, Adobe's working on one additional change that so we can actually provide multiple endpoints per resource. So not only will we have the fail over capability, but if we create an A.P.I. an A.P.I. manager and then we have four or five different resources inside that A.P.I. that we've created, we can actually point them to separate end points. So to the user in the outside world, if you're calling me right now, you're calling the A.P.I. manager and A.P.I. that I've provided you that endpoint.
You have no concept or any kind of clarity on what actual endpoint I'm calling on the call. That's off skated from the subscriber, the consumer through the API managers. So it allows us to point any A.P.I. to any different technology stack that we made have running in our environment. And so the user, they have no idea. They see this really nice, clean, restful endpoint and then there's a whole bunch of translations that happen under the hood on the time of the request. But it really makes it implementation very clean. And to the user on the outside world, they have literally no idea what they're calling once they go into the API manager other than what they've been told and the documentation has been provided.
Michael: That is great! And then what about controlling how much they're allowed to call the A.P.I. Can they just call it millions of times or can you control? You know [crosstalk] [23:19] open up an A.P.I. people could do anything, right?
Brian: Sure yeah, it's a whole entire system. You're giving them access to your data. Know that's a great question. The A.P.I. manager does come with an SOA interface. So for each end point, you're able to establish a service level agreement, and that includes not limited to. I mean you can put up… The beauty of it is that I can create all these multiple plans. So it comes with a couple out of the gate by the API manager. It comes gold, silver, and try it now. But we have the capability of actually going there and creating an actual SOA [inaudible]. So I could create one for you today, and it's customized for you. And I might say your access is 5,000 requests per hour, and I'm gonna give you a soft failure of ten percent.
So if you go ten percent over, I'm going to let you do that. But then I'm going to start to cap you and say, “Hey, it might be time for you to upgrade your account. You need to go to the platinum which is 20,000 requests for our 30,000.” So we have the ability to really make sure that we lock this down so we don't get any kind of denial or there's no attack. And if someone's trying to maliciously take us down or anything like that, that can all be prevented very easily. The nice thing is that it's not capped at… You know a few plans. I can literally go into the API manager today and create 1,000 different SOAs and I can assign them per resource as I create them. And they have hard failures, they have soft failures.
I mean anything you can think of; percentages that you get with and maxes, we can put notifications. So if I have somebody who's abusing it or constantly hitting that max, I can go ahead and reach out to them and say, “Hey, you know either you don't something malicious here, or your business is growing. I think you need to be out. We need to talk about a new strategy for you for this year.” I tell you one thing that I really think there's a lot of potential is at some point; we may want to charge for this data. There are A.P.I.'s out there that do charge, that do regulate based on an SOA, and there are some advantages here. If we can find tie e-commerce parts of this which I think are more capable, we have a plan on how to do that then we could start to charge for plans.
You might pay for gold or platinum, but the tool would allow us to manage this. And we could upgrade and we can monitor, and apply notifications on to help us manage it. But all that exist and there and it's just as good if not better than some of the other platforms that I've looked at. It's very easy to use. We have business owners that can set this up. Their own might not be as technical because the [inaudible] [25:44]. We've got one owner in particular; a business owner who is not coding A.P.I.s but he has no issue managing the tool. I mean it's that easy, the intuitiveness is very basic. I mean you can have an A.P.I. upgrade in five minutes and you'll be in production. It’s that great.
Michael: Wow! It's great and then I think that you mentioned earlier you do some versioning on your A.P.I.s. What you know maybe folks who aren’t using this aren’t familiar on why you'd want to version your A.P.I. What is that and why would you do it?
Brian: So this a particularly big challenge for us right now because we're in this migration state. So we have this Layer seven product that we're on for many years and we're still in the process of migrating off that. But of course the challenge with that is you don’t need [inaudible], there that aren't easy to get through, the building review process with depending on which vendor you're dealing with. And so if we come back home and say, “You know we've moved our A.P.I.s. We have brand new endpoints, we have brand new A.P.I. keys, we have brand oauth credentials.” All that's probably gonna make them scream because I mean you're talking about coding changes which cost money; production, loss of production time which can cost money.
The review process which is expensive. It’s just a huge pain. So one of the challenges that we want to make sure that we cover when we worked with all the internal teams with migration process was versioning. The idea of versioning is it basically if I have an endpoint today and I make a change to it, as long as the contract doesn't break between you and me, we’re fine. There's really no reason for me to version the A.P.I. But the truth of it is that if I don’t make that change, it breaks the contract where your code today that's calling it working in production suddenly stops working, frozen error, we got a problem, and that's where a new version would be created. So at that point, we would make the case the version.
The A.P.I. manager is well suited to do that because it allows you to go and create that A.P.I. with a new version, a new endpoint. And you can start to test that and actually put it into a beta state or even a production state without worrying about all your consumers on the version one. The nice thing about the API manager when it comes to this is that there's notifications baked into it so I can know exactly who's using the old endpoints. In the past where there was no A.P.I. manager, I have honestly it's a combination of spreadsheets, word documents, emails, slack messages, or whatever the case was to try to figure out who's going what. So the API manager it's very clean on who's actually subscribed to it.
You can see the security mechanisms around it and any other the meta details or the data details that you would need to version successfully not break anybody. As far as the versioning goes, we've been pretty lenient on supporting the back versions. It's not always that we can be backwards compatible, but we're pretty generous as far as continuing to support an old version. But we really we try to hope to get people off the old version especially if there's been a code improvement or enhancement as far as speed goes. And I have to say adding to that, the other big thing that we've really been working with Adobe on was that migration plan. They know the pain as well since they're in the same process of coming off CA's as well. The A.P.I. keys and particular been able to override A.P.I. key.
So we actually have a feature that was baked back into the Adobe API manager where it allows us to actually take an A.P.I. key, or even a oauth key from CA's account and actually point to the A.P.I. on the Adobe API manager we can actually bring in migrate those keys over with us. So it's to the point where there's literally zero programming changes for anyone who subscribes to the endpoints which is a huge win for the product in the migration.
Michael: Does it help you manage your keys? Because I know when I've worked with A.P.I.s it's keeping track of those pain in the rear end.
Brian: Yeah, it's true and it out usually put them somewhere and I forget I have to go get generate a new one.
Michael: right
Brian: It’s a bit of a challenge. And yeah, absolutely does and fact the it's very clean. So when you have an account, so if I'm a subscriber I would have an actual log into the system, I would go to log in and see all my applications. So what you actually do is you create an application. You could call it shopping cart and then you could have a search, and then you could have a product detail. All these applications you can create, and each one of those applications will always have credentials associated with it.
So you have an A.P.I. key, you have an oauth credentials, and that key is assigned to you and your users. So as you start to subscribe to APIs, you can actually assign your debt your application whatever you create it to be the subscriber default or the subscriber application to that A.P.I. So for example, if there's a bunch of shopping cart APIs from a call from a third party, I could go into my account, I can create a application called shopping cart. It would give me all the credentials that I need, and then I can use that to subscribe to the shopping cart API.
So from a subscriber standpoint, it makes it really easy to manage and see and you can track your own traffic. But then also from a publisher standpoint, from my side, it allows me to see exactly who subscribes, what A.P.I. keys are using, what SOAs they have and all the information I would ever need. And that way if there's any abuse or anything like that, I can always quickly shut it down and I know what application’s causing it. And from a subscriber standpoint, it allows me to start to segment my different A.P.I.s and my accounts very easily. It's all displayed on a really clean interface and extremely intuitive and easy to use.
Michael: So if you have to summarize why someone should be using the ColdFusion A.P.I. manager, what would you say?
Brian: I think the main reason to me is that it is almost completely necessary. If you're building any kind of A.P.I.s whether they be REST or SOAP that you have these management tools at your disposal. There's no way to effectively manage an A.P.I., to develop the A.P.I. for the process and the analytics without a tool like this. I mean an A.P.I. manager tool is well suited for an enterprise level. You know shop even a smaller shop and that's the beauty of it. You know it will scale with you. But I would say it's detrimental. It is… one problem the most important things that you could have in trying to run a successful A.P.I. environment especially just the sheer management of it.
All with things that we've talked about from analytics, to debunking, to logging, to tracing, to account creation management; that is virtually impossible without it and trying to manage an entire infrastructure A.P.I. as well that is why I would think it would just become to the point would be unmanageable and frustrating and eventually lead to a lot of performance issues, development issues, and not to mention management issues on top of that.
Michael: Cool! Now I noticed in your talk you mention a thing called swagger. What exactly is that, and how does that relate to all these API stuff?
Brian: Right so the tool is again very unique and this is where definitely had a lay up on CA's layers. You know Layer seven product where I can take a swagger endpoint and actually go into the A.P.I. manager, very easily hit create REST A.P.I. from swagger which is one button click. It will open up and then I have a couple options. And one of the begin enhancement that we actually got from Adobe was we wanted to be able to do direct input of swagger text. We also want to be upload a swagger file and then we had the link that was already provided. So Adobe delivered insanely fast and gave us these feature set. We felt like the product is now… there's no way you can't use swagger to build an A.P.I. in there. You have one of three options.
But swagger is you know I think it's probably been one of the more popular ways of constructing A.P.I.s today to get all the metadata documentation, and that swagger file can be directly imported. It will create all the REST endpoints for you. It will create all the methods. It will create the name, the context, the versioning, you can even put a logo image in there. But basically, this file can be used to generate an entire collection of A.P.I.s and all the resources within a second. And it saves all the manual time and the labor. And even if you're doing anything like annotations in ColdFusion, you can utilize some of the A.P.I.s under the hood that A.P.I. manager offers because every feature and the U.I. that you see in the A.P.I. manager is also available in A.P.I. format.
So you can programmatically build an A.P.I. in your S.T.L.C. If you're generating swaggered docs, you can have a swagger doc automatically or programmatically fired at the time of any of your steps in your S.T.L.C. Or even at any point, you can auto generate these APIs and reduce even more manual labor that's required. And that is a feature that I have not seen in any other A.P.I. manager to date and it is a thing of beauty. And I know that the pet store demo is always a good one. But if you have a swagger doc today and you log in, you definitely you can have an A.P.I. running in a matter of seconds.
Michael: Sounds like you've done great work with this stuff, and you’ve not only been using it in Market America, but encouraged Adobe to really step up on this API manager product.
Brian: I think it has a great chance. I think it just needs more users from the community to embark on this mission. But I thank you, yeah. And Adobe. I can't say enough, but the partnership will continue to grow and I really see this product continue to blossom and become even more vital part of Market American shop.com.
Michael: Yeah, have you used any of this stuff to do automation or with your software development life cycle at all or?
Brian: Yeah that's actually the part that we're implementing right now. We’re making some changes. You know we’re embarking more micro services at this point. That’s definitely another area that we're starting to venture into. And because of that, we're trying to automate as much as possible, automated builds, and a number of other steps that we can help [inaudible] automate sort of have a manual today. But the A.P.I.s that have been built with the A.P.I. manager including things like the swagger A.P.I. creation. Yeah, that's the plan.
We're gonna begin to annotate more and more of our code and we're gonna start to use those annotations and some of these bills to generate documents, and then also start to fire some of these A.P.I.s and A.P.I. manager to help automate the process. I mean ideally, what we're really looking for is to be able to have a developer write an A.P.I., publish that A.P.I., go through a workflow. And at that point, he needs to do nothing else or she needs to do nothing else. It's literally just point, click, automate, and then it will go through our lifecycle without any kind of struggles or forgetting steps. But the idea is to this tool will help us get to that point. I'm not sure we could do what we wanted to do without it.
A lot of this automation was unavailable and the CA product, they had no A.P.I.s exposed. We had no way to automate or programmatically build things on the fly. And that was a big thing that we really are a pushover they be manager. In fact you could probably move all of the Adobe A.P.I.s into that A.P.I. manager and use those as your first A.P.I. as one of the things we had mentioned Adobe. And I think they got a good laugh out of it. But it makes sense I mean we can expose some of these A.P.I. which we're doing for the portal. [Inaudible] [36:51] it into a word press site to automate like sign-ups and registrations from people that wanted it or hello world, learn more about our company you get an account.
This is all manual before these are steps that we had somebody had to take a phone call or an email, and go on creating account you know credentials. Because the fact that we have all these A.P.I.s, we're able to expose those to any site or any platform and actually automate that process. So it requires a lot less man hours and quite honestly, it allows us to stick to what we do better and that's writing A.P.I.s rather than managing A.P.I.s.
Michael: Well that's great! Well good luck in your talk at CF Summit in a few days. Let's just change gears a bit. And let me ask you something I've been asking all the people I've been interviewing on the show which is, why are you proud to use ColdFusion?
Brian: I want a product for a long time. I started with it in college and my first job and 2006. So it's been I'm just about coming up on 11 years almost 12. I have that in a quite a few languages. I do some java, do some P.H.P. and obviously all of the front end technologies as well. The simplicity and the performance gains and just the commitment to the product over the last few years has really made me continue to want to explore ColdFusion. I have seen personally a big change in Adobe. There were years there that I think ColdFusion suffered. There was a transition there that I even was very nervous about. There were some years there I was concerned about where the direction of language was going.
I don't know if it's just the new management with Adobe or a number other things that maybe it's you know, Rakshith might have a huge part of this. But there has seemed to be a better commitment amongst the community. The direction of the language as improved. It seems like the road maps have improved. I mean they've got conferences now. There was a long time where there were zero conferences. There just seems to be an actual commitment at this point to continue to support the language and grow it. And when you see things like the Adobe A.P.I. manager come out, they know the direction things are going. I believe the next release from what I hear is really focused on speed and performance, and better debugging, server level tuning; things like that.
As you know tags and these cool little functions; that's great. But at the end of the day, I don't think that's where the direction of the language should go. I think it's down the path they’re going. It's to try to make it more performant. And to make it more of a scalable language. I know they're trying to look… They're gonna release their first docker container here in a couple of days. They're trying to get in micro services, they’ve talked about a number of things. I think that the language has a strong stance moving forward, and I think that they're playing their cards right. I think they know the direction of where they need to go. You know and I hear all these negative things I read.
You know everybody ColdFusion is dead. I know that debate goes on and on. But some of the things that really bother me is all time our talk right here about people not be able to find talent that the ColdFusion programmers just don't exist. We have no trouble. We've got over 30 developers where I work and I will put up any of them against any other programmer, anywhere against any language any time, and I think they would hold their own. I'm very proud of all of them. They're all excellent developers. And honestly, we build applications faster than any shop. I know where an e-commerce platform that does almost a billion a year. We've never had an issue with the language. It performs extremely well and it just proves the point that the language can do what you want it to do.
It's all about how you use it, how utilize it, and the people you put behind it. So this garbage about how we can find people who are not as good, they're not a sharp as a Java developer. I would disagree with that and I can prove it. We do it every day and I don't doubt for a second that there's not a ColdFusion developer that can hold their own with a developer at any other shop doing any kind of application. So the language is here to stay I think, and there seems to be a big commitment. And as far as Mark American shop.com go, we're going to stay on the product line and the A.P.I. manager has a home and we're going to continue to grow it. We’re really excited about the future.
Michael: That's great! So what would it take to make ColdFusion even more alive in the next year?
Brian: We need more people to commit to it. We need a ColdFusion community but the people that come out for this conference they need to get on board with these kind of things this is the direction of where it's going really important. We need to get away from tag development. We need to get away from the simplistic approach of ColdFusion starts he's more of the modern features that are available and that have been available for many years. But for many years it's either ignored or it's just a lack of education. I don't know, but I can see it in the conferences every year. I think you know in person, I think the developers are getting better. I think they're understanding concepts more. They're starting to adapt more of the technology especially around REST, and the A.P.I.s.
And I think there's a general change from what I see. So but if we can continue that and grow the language, I think it will only help with companies especially managers that have to make decisions on technology. They can start to see some of the advantages here in that it is a viable candidate. I would like to see Adobe get more aggressive on their licensing. I think that's one area that they can definitely help out the ColdFusion community and start to grow it. I think that maybe it would be a more attractive opportunity for companies if they can get more competitive, and I think they realize that. And honestly, even with the micro services we're working on that right now.
They've been very open to our ideas, and I think they see a lot of potential for growth there. So if this… If ColdFusion to me is going to make it, this is where we need to focus we don't need to worry about tags, doing cool little things and you know clients that do mobile phone generation that there's that space is already eaten up and I would let them have it. The focus should be on the application making it as performer as possible, making a licensing attracted to managers or owners and really seeing the language grow from that aspect. Because I think it has a lot of potential and a lot of fighting room and that space.
Michael: That is great Brian. Well sounds like you're doing a lot yourself to lead this there at Market America and also in the community you’re in. So appreciate everything you do for ColdFusion.
Brian: Thank you very much. Same to you
Michael: Well thanks, yeah. I like running those CF Alive podcasts because I wanna make ColdFusion alive and see it as a modern successful language which is what it really is.
Brian: absolutely
Michael: Since its inception. You know I talk to lots of people who use ColdFusion all the time, so I know that’s what's really going on. So anyway, you're going to be at C.F. Summit in a few days. What are you looking forward to in this year's conference?
Brian: I had quite a bit of the A.P.I. conversations. I was looking at the agenda in the… tonight, and I can see that it's gonna be a hot topic. So overly I'm speaking early. I get the 1:45 slot on Thursday. So hopefully, nobody's drowned out with APIs by that point. But just looking at the topics in general, you can really tell the direction that I think most of the speakers and Adobe itself is recognizing and the networking. It's always good to go. I mean what better chance to talk to Adobe's engineers and they're I mean you're getting face time with the guys that are building the product; that's a rarity in this business in my opinion. And that hands on one on one time with them has been fantastic.
We have gotten bugs fixed, and updates, and questions that we've had over the years or even months, or problems that we run into answer to resolve right there on the spot. So I don't think people value that as much at all. Maybe not an either it's underestimated or maybe more people should take a challenge. I mean they've got an entire table set up with every engineer on the team there. And it's a knowledge building session you go up there for ten minutes and probably solve all the problems that you had over the last year six months. But there's a lot of opportunity there and I think that's it and you know that's what I'm most excited about. I mean this conference is literally why the A.P.I. manager is what it is for us. It came out of a conference and I would encourage everybody to go talk to Adobe and really voice your opinions.
They're very open from my experience, so they've never shut us down. They've been very happy to accommodate us and I think you just gotta ask, maybe it's the fear of asking. But they seem to wanna make this language better, but it starts with us too. I think the key has to realize that if Adobe’s gonna continue to grow ColdFusion, we have to make a commitment to make it a language better. We can't just do things the old way, or the same way, or take the easy way to get things done. The language is only gonna be as good as developers are using it. And if we're going to continue to grow it, Adobe needs to see the same commitment from a development group as it does from the engineering group.
Michael: That is a great call to action for everyone here listening. So if people wanna find you online, what’s the best way for them to do that?
Brian: Yeah, my social media is lacking a little bit, but I would think LinkedIn is probably the best route to go.
Michael: We’ll put the U.R.L. to your LinkedIn profile in the show notes. So I think you're the only person with your name in Linked In.
Brian: I'm very unique; that's correct. I have yet to meet another Brian Sappey; that's for sure.
Michael: Cool! Well thanks so much for being on the show today, Brian.
Brian: Oh thank you very much for having me. It was a complete pleasure and I really do appreciate what you're doing for the community, and continue to keep it up. And if I can help in any way, I'd love to.
