John is EMEA Integration practice lead based in the Lightwell UK Offices. John has previously worked for IBM as an MQ strategist and architect working on next generation cloud messaging solutions and messaging appliances. Since leaving IBM John has continued to focus on both integration and cloud technologies such as IBM PureApplication Systems, MQ and, more recently, API Management.
API Management promises a nirvana of exposing and securing data using well-known and simple techniques. Vendors focus on how easy it is to create the APIs and nearly always mention security as part of their API lifecycle story.
Yet, we've all seen the headlines screaming the latest security breach. So, what does “Security” really mean when it comes to API Management?
In this post I’ll try to differentiate the basic policies that all vendors discuss from the many other attack vectors that we need to be aware of.
When I first joined Lightwell, I was struck by how everyone discusses "onboarding." What was this magical and mystical thing? Why was it discussed in such reverential tones? Having analyzed this further, I'm still a little mystified as to why the hush tones but I'll put a few words down here about what I consider onboarding to consist of and why it's as much a human process as a technical challenge.
It's clear that onboarding of partners is where much time is spent in a B2B system. That's why business people consider it a large factor in their projects. Not only that, but I've found that the more technical people discuss onboarding related to the technical aspect only. Whereas, in my opinion, a lot of the onboarding process is actually about human interaction.
Although the offerings I'm about to discuss are different, they're interesting enough to explore more closely. Both IBM and MuleSoft are claiming that the reason for implementing their solutions is because they perceive a lack of skills in containers and Kubernetes.
This tallies with what I see in the world I work in too. It's one thing to say that you can run a few containers in the wild, but it's quite another to run them as a true cloud environment with hundreds— potentially thousands—of them.
Alongside this, containers are making some architectures change. High Availability (HA) solutions that once looked fine in the VM world now begin to look clunky and new ways of doing HA are springing up. Monitoring now becomes a headache if your failing system was brought down automatically and had been recreated before you even knew you had a problem. Never mind things like license management, where most vendors are struggling to cope with a more flexible model that true cloud requires.
I'll discuss here the two different offerings, and we can see how they are very different—but trying to solve the same skills issue.
In a previous post, APIs vs EDI: Complementary, Not Competitive, I shared my perspectives on the evolution of APIs along with EDI. I'm going to expand on this topic with the idea that agile methodologies may have more to do with the current proliferation of API Management than the usurping of EDI.
Let's be clear…EDI is most certainly here to stay for a long time to come. I've read many articles and debates on this subject but, for me, what it comes down to are those well-known business interchanges.
We can't just ignore the fact that EDI has evolved to where it is today because business needs well-known formats so that they can communicate with each other in a standardized manner. APIs, at the moment, simply don't have those standardized formats. When a company creates an externally-facing API they are, today, writing their own business interchange format (i.e. trying to reproduce an EDI interchange).
Now, that's fine, however, if each company is going to create its own format then communication between companies is going to revert back to being a spaghetti mess of protocols. This is exactly what EDI was meant to overcome, and why EDI has been so successful for so many years.
Every time I see a "Blockchain 101" post, inevitably, it mentions Bitcoin. That’s telling you about a specific use of a blockchain technology rather than describing what blockchain technology is and what it can do for you in general. So, I figured I'd write the more general “what is” version. I’ll also touch on what it takes for you to work with blockchains.
By the way, I'm going to try not to mention Bitcoin again here. So, let's go...
Traditionally, if parties wanted to track assets—let’s say cars—these assets would be tracked by separate parties keeping their own individual records. Those parties can alter those assets (buy the car, sell the car, be the insurer for the car). However, this is inefficient and prone to error.
API Management is a hot topic at the moment. Many have heard about it and have seen the flurry of products that have been introduced into the market in recent years. However, when speaking with our customers, it's clear to me that many do not know exactly what all the elements are that make up API Management. This can lead to a lack of understanding of the architecture and sometimes the benefits of API Management for their business. To help address this, we have created this post to help break down API Management into its constituent parts and help you see how your organisation might benefit.
Back in the day, Web Services were the de facto standard for accessing "systems of record." Out of this grew the secured ESB architecture that is synonymous with enterprise architecture.
More and more, projects are utilising API Management in those architectures now and pushing on Web Services' door.
In this blog, I'll explain why social factors—as much as technical ones—are enabling API Management to make inroads into 'traditional' SOA architectures. I'll also show that API Management is much more than the "API Economy."
It’s hard not to notice the up-swell of API Management in the press in recent times. If you come from an EDI background you may dismiss API Management as not being relevant. I also often hear the contrary view: that EDI is old-school and that APIs are taking over.
I don’t believe either to be true.
There are plenty of Qualities of Service that EDI gives in spades that API Management simply doesn’t touch and vice-versa. In this blog I’ll review those differences and show how API and EDI are complementary technologies, not competitive ones. I'll also suggest where the future lies for these two differing technologies and that, actually, the comparison isn't EDI vs API—but should be API vs Web Services.