Category: Reaction

Hmmm, SOA is a bad word? So let’s call it APIs !

2012-December-14

David Linthicum, in his InfoWorld article, observes that SOA is a “bad word”, noting that SOA Companies are now rebranding themselves as API Management companies.

Some editor at InfoWorld apparently chose the article title to be
“Service governance morphs into cloud API management”. But I don’t think that’s an accurate summary of the article. That’s not the gist of it.

The gist is more accurately captured in Linthicum’s subtitle, to wit: More evidence that SOA is a bad word: Traditional SOA service governance technology rebrands itself for the cloud.

Re-branding is the first baby step in the “morphing” process I guess. But sayin it don’t make it so.

The problem with the rest of Linthicum’s anaylsis is that it looks at everything through a SOA lens. API Management exposes APIs – “that’s SOA” he says. API Management platforms enforce security controls. “That’s SOA governance.”

Great, I can see the parallels. But what about the things API Management platforms do that are completely outside the domain of SOA? What about developer enablement and engagement? What about analytics? Versioning, cloud-based scale out.

Linthicum is an SOA guy, and when he looks around, everything is tinted with his SOA-colored glasses. I have a different perspective. SOA solved some big problems. As a metaphor for interconnecting enterprises, it was a huge advance. A huge improvement.

Even so, with SOA there were problems. Poor support for mobile devices. Still a great deal of complexity. Hard for developers to get connected and productive. Poor visibility by business owners into the impact of applicaiton inter-connect traffic. API Management platforms present an opportunity to address all those challenges.

Despite what Linthicum sees, API Management is not simply re-branded SOA.

Are DDoS attacks a novel threat to API servers? Nope.

2012-November-16

Mark O’Neill, CTO at Vordel, published a post on programmableweb regarding DDoS attacks and the implications for APIs.

For those who learned programming before Friends became a hot TV show, the term of art “application programming interface” referred to the function names and signatures that you’d link your program to. These days, the term API refers most often to a Web API, in other words network interface, often a REST-based network interface. One program sends another program an HTTP request, and gets a reply of a given form in response.

I think O’Neill made things sound waaaay more dramatic than they actually are. The term that he used – “Soft underbelly” – was intended to imply that APIs represent a special vulnerability on the Web. That’s simply not accurate. API interfaces are just a “regular underbelly”, to coin a phrase; json access is just like html access. DDoS is a risk and it can affect json servers and html servers alike. O’Neill doesn’t provide any specific advice on why API servers are different, or what special steps need to be taken to protect API resources.

He does make some reasonable points : (a) that API access was given short shrift in the original reports; (b) that APIs are likely to rise in importance as the usage of mobile apps grows; and (c) and that hosting APIs separately from www traffic (on api.mybank.com vs www.mybank.com) might/could have mitigated problems.

But API management platforms such as the one sold by O’Neill’s company, are not likely to be effective against any non-naive DDoS. In fact the existing DDoS mitigation techniques, using network devices, are all we need to protect APIs. “Nothing to see here, move along.”

I understand that hype will attract attention to the post and to O’Neill’s company. On balance though, I think he’s doing more of a disservice to APIs by exaggerating or even mischaracterizing the risks.

Reference: Intro to Distributed Denial of Service attacks

Disclaimer: I work for Apigee, which is a purveyor of API Management solutions. These opinions re my own.

NoSQL is apparently NOT going to deliver World Peace

2012-July-17

Peter Wayner at InfoWorld has articulated “Seven Hard Truths” about NoSQL technologies. Among them:

  • It’s nice to have JOINs; NoSQL has none.
  • It’s nice to have transactions
  • After 30 years of development, it seems that SQL Databases have some solid features, like the query analyzer.
  • NoSQL is like the Wild West; SQL is civilization
  • Gee, there sure are a lot of tools oriented toward SQL Databases.

Intereesting synthesis, but nothing really novel here. Michael Stonebraker articulated these things in 2009, and lots of people who’ve built information-driven companies in the past 6 or 7 years on traditional SQL datastores had the same insight, even if they didn’t bother to articulare it this way.

SQL Databases work. There are lots of tools, people know how to use and optimize them. The metaphor is well understood, the products are mature, the best practices are widely disseminated throughout the industry. None of these are true with the big NoSQL technologies.

There is value in NoSQL. Some very successful companies have considered SQL stores and dismissed them as inappropriate or inadequate to their tasks. Facebook, Google and Twitter have famously used NoSQL to accomplish things that would not be possible with technology that has evolved to serve the needs of traditional transaction-oriented enterprises.

Ironically, the shiny object that is NoSQL has now captured the attention of IT people in traditional enterprises, the very audience that the designers of NoSQL technologies ignored when producing their solutions. Does this make sense?

Yes, there’s a place for NoSQL. No, it will not take over the world, or replace the majority of enterprise data storage needs, anytime soon.  There are opportunities to take advantage of new technologies, but unless you are the next Twitter (and let’s face it, you’re not…) you probably do not need to emulate the Twitter data architecture. What you should do is combine your existing SQL data strategy with small doses of NoSQL, deployed tactically where it makes sense.

 

PHP Makes People Sad

2012-July-11

Just read an enjoyable rant entitled PHP: a fractal of bad design by a nerd who calls himself Eevee.

A good effort!

I also found a link to PHP Sadness there, and a bunch of other links to sites that complain about PHP.

This kind of criticism is correct, and valid, but it’s also pretty common, and low-hanging fruit.  I mean, come on.  We all know this stuff, right?  We just haven’t bothered to catalogue all the problems.

The other problem with this criticism is … reality.   PHP has had these problems since forever, and if they were really so significant, then no one would use it at all.  So there is something of value in PHP, and some part of it’s design is helping people get things done.

Yes, there are a million pitfalls.  Yes, there is a lack of consistency across a broad swath of the PHP built-in libraries. But apparently the people using PHP don’t suffer all that much for it.  Lots of people use PHP to build simple systems quickly, without getting all tangled up about whether to check exceptions or not, or whether “1” is the same as 1.

If you want a beautifully designed and consistent programming language environment, PHP is not it.  Ok, then.  Move along. No one is forcing you to use PHP.

 

Do you think “Cloud Computing” is vaguely defined? Dell disagrees.

2012-June-15

I was reading through some of the Microsoft chatter surrounding TechEd, the company’s massive annual technical conference.

One of the blog posts got my attention with this headline:

I wasn’t clear on just what that meant, so I clicked through, of course.

The biggest news there is about System Center, which is an IT Pro management tool. Apparently the latest offering has some new features that help sysadmins manage “private clouds”, which I suppose refers to on-premises pools of computers that are allocated out in some flexible manner. Sounds like useful stuff. The proof is in the pudding of course.

But the thing that caught my eye was one of the partner news items. A “cloud offering” from Dell.

A Dell rack filled with storage and compute
Dell's Impression of a Cloud

OK, now I know what Dell thinks a cloud looks like. 🙂

Is Microsoft a Cloud-first Company?

2012-June-14

Microsoft is a Cloud-first company, asserts Jonathan Hassell.

Not sure that’s completely accurate, or helpful.  He’s right that Microsoft is accentuating the cloud offerings, these days, and is really pushing to exploit what is a once-every-two decades kind of disruptive development in the industry.

On the other hand the lion’s share of Microsoft’s revenue still derives from on-premises software, in its “traditional strongholds.”

Apigee’s Best Practices for REST API design

2012-May-17

I just read Apigee’s paper on pragmatic RESTful API design.

Very sensible, practical guidance. Good stuff for organizations confronting the REST phenomenon.  There are obviously many REST-based interfaces out there. Facebook, Google, Digg, Reddit, LinkedIn are just a few of the more visible services, coincidentally all social networks, that support REST.  But of course there is real value for enterprises in exposing resources in the same way. Wouldn’t it be nice if public records would be exposed by your municipal government via REST?  How many times have you wanted the data from a hosted app – what we used to call “application service provider” – in a machine-comprehensible format, instead of in an HTML page?

It’s worth examining the results the pioneers have achieved, to benefit from their experience.

As pioneers rushing to market, the designers of these early social network APIs may have sacrificed some quality in design, for speed of delivery.  Understandable. Apigee’s paper critiques some of those designs, and describes some of the rough edges. It’s like sitting in on a design review – and it’s an excellent way to learn.

Once you “get” REST, it all makes sense. It falls into place and the design principles and guidance offered by Apigee will seem like second nature. But for those grappling with a novel problem, it’s good to have a firm foundation from which to start.