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.Continue reading
"App Connect" ring any bells at all?
There's more to this than just a renaming of IIB—IBM has added in some IBM WebSphere Cast Iron capabilities and they've created a new IIB GUI as well.
In this blog entry I’ll go through these changes and look at what it means in the long-term.Continue reading
Did you know that IBM merged a number of their top conferences—Interconnect, Amplify, World of Watson, Edge, and Connect—into one in 2018? If you haven’t already heard about it, IBM Think is IBM’s new flagship business and technology conference, taking place March 19–22, 2018 at Mandalay Bay in Las Vegas.
It’s a global event where over 40,000 business and technology innovators, leaders, and thinkers will gather in one place to share ideas, discuss topics like Artificial Intelligence, Cloud, Supply Chain, Blockchain, Omnichannel Commerce, Data Analytics, Integration, Security, IoT, and more—and enjoy some exceptional networking, entertainment, and fun along the way.
While there are many reasons to attend—including a few mentioned in the video below—you may be most interested in reading the highlights so that you can make plans quickly (the event is just weeks away). So, as someone who has attended quite a few conferences over the years, I’ll share in this post what I believe are some of the best reasons to attend. These are in no particular order.
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.Continue reading
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.