Layer 7 Logo

Last in our series of posts looking at API management platforms is Layer 7.

The Layer 7 API Management Solution evolved from their SOA gateway products, which Smart421 has been tracking for a number of years. Computer Associates (CA) acquired Layer 7 on 22nd April 2013, with the Layer 7 products becoming a key strategic element of CA’s security product portfolio.

The Layer 7 products can be deployed in four ways: as hardware appliances, as VMWare Virtual Appliances (i.e. packaged VXDs), as Amazon AWS Machine Images, and as a traditional deployable software package. Different product ranges apply to each deployment approach, but all options use a traditional perpetual licence arrangement with annual support. Exact licence terms and costs vary by deployment approach, but are in general are based on the performance of the hardware.

For companies that prefer to use hardware appliances, terms are significantly less onerous than other appliances (e.g. IBM DataPower), as hardware and software licences are paid separately, so replacing hardware doesn’t require a new software licence. Equally, software upgrades for appliances are provided as a standard part of annual support for as long as the hardware can support them, rather than being firmware upgrades which are provided for a shorter length of time.

Alongside their core API management products, Layer 7 have a software as a service offering known as APIfy. This proposition is currently in beta, is free to use, and could be an interesting deployment option for customers if a clear upgrade path to the full product becomes available when it leaves beta.

The Layer 7 products support all the features you would expect of an API management platform, but because this platform is based on Layer 7′s mature XML gateway product, it also supports very extensive and flexible features for traffic management, custom security, message encryption, transformation, and routing. The core API management functions have been implemented using the same SOA gateway primitives available to developers, which gives a good indication of the power of the gateway.

Advantages:

  • Long history of providing high security SOA gateway technology is an excellent foundation for deployment in blue chip organisations with stringent security requirements. Supports a wide range of security technologies, e.g. SAML, X.509, LDAP, OAuth, OpenID and Kerberos.
  • Very flexible technology providing support for esoteric/unusual environments common in enterprises. Supports protocol transformation (even down to TCPIP sockets), complex routing, orchestration and parallel execution.
  • Extensible with Java plugins.
  • Flexible deployment models, on prem and in-cloud.
  • Very strong scoring by both Gartner & Forrester
  • The only of the 4 vendors offerings which is available from the AWS Marketplace (but still using a BYOL model)

Disadvantages:

  • Unlike e.g. APIgee, there is no ‘free’ version that can be used for a production pilot with easy migration to the production version. This may change once APIfy leaves beta.
  • Traditional commercial models only – no pay-as-you-go option, although licences are available for trial use.

When would we use it?

  • Enterprises requiring high-security on premises deployment with virtual or hardware appliances.
  • Enterprises wanting to deploy a custom solution within an AWS virtual private cloud (i.e. where all components are hosted within the client’s virtual cloud rather than on the public internet).
  • Enterprises with complex integration requirements (e.g. integration with MQ, databases, TCP/IP sockets etc).

Next in our series of posts looking at API management platforms is Mashery.

 

Mashery scored well in both Gartner and Forrester reports. Mashery were acquired in April last year by Intel. This has strengthened both Mashery with the backing of a company the size of Intel, but also provides Intel with a way into the API Management market place and aligns with their recent shift towards the software market (e.g. through the acquisition of McAfee)

The Mashery product provides similar features to the other products, and can be deployed both in the cloud and on-premises. Integration between Mashery and Intel’s Expressway Gateway appliance will also add comfort to those customers who are used to having a physical appliance on premise.

Interestingly, Mashery’s marketing message revolves as much around internal APIs as public ones: Something we agree with wholeheartedly.

Advantages:

  • Strong, feature rich product (including protocol translation; SAML, X.509, LDAP, OAuth, OpenID support; policy enforcement etc).
  • On-premise, Cloud and hybrid options available which provides flexibility when engaging with customers
  • Strong presence in the UK markets with the likes of Argos, TomTom, ASOS, Experian etc using their products
  • Developer portal is strong and Mashery I\O docs are a differentiator to other API Management systems
  • Backing of Intel likely to lead to significant investment into the Mashery products

Disadvantages:

  • Risk of potential product consolidation as a result of Intel Acquisition, although no sign of this occurring yet.
  • Like Apigee, in our opinion the enterprise security story isn’t quite as strong with the core Mashery product as with some other options, although this is bolstered by integration with Intel’s Expressway appliances.
  • Level of sophistication of the integration with Expressway was unclear in our investigation. It might be brilliant, but we’d advise further investigation.

When would we use it?

  • Deployment where quality of portal experience is paramount (including the documenting of APIs – I\O Docs helps with this!).
  • Where a customer is an existing Expressway customer, or has a strong preference for physical appliances and/or Intel networking kit.
  • To utilise the enhanced capabilities such as  pre-packaged reporting for internal and/or external use , policy enforcement or protocol translation.

logo-3scale
Next in our series of posts looking at API management platforms is 3scale.

3Scale offer a SaaS API Management Solution which differs from the other API Management Vendors in the way it handles API traffic. Rather than traffic passing through a centralised proxy, 3Scale provide a series of open source plugins, allowing decentralised processing of traffic. These plugins can be installed either within individual applications, existing ESBs, or within on-premises or cloud hosted proxy servers running Varnish or Apache HTTP Server. 3Scale also supports integration with the Akamai Content Distribution Network allowing authentication, throttling and caching to occur at the network edges.

Regardless of chosen deployment methodology, API traffic does not traverse or get stored within 3Scale’s infrastructure, eliminating a potential scalability bottleneck, and easing any potential concerns about security particularly given recent revelations about national intelligence agencies’ ability to conduct surveillance on private communication lines.

3Scale is a simpler product than many of the others, and therefore does not support e.g. message transformation or routing. Smart421 would therefore recommend 3Scale is deployed alongside existing integration infrastructure. 3Scale’s plugin architecture should allow 3Scale capabilities to be added to an existing ESB technology.Whilst they didn’t score as highly in the Gartner and Forrester reports, 3Scale do have some big named customers such as Skype, Telegraph Group, The Guardian and JustGiving.

Advantages:

  • Simple, low pricing.
  • Free tier allows POCs and Pilots to be built and deployed cheaply and easily.
  • Clean simple architecture supporting both cloud and on-prem deployment of traffic management components.
  • Solid core product including authentication/authorisation, developer plans, developer portals, forums and billing engine.

Disadvantages:

  • Not as feature rich as some of the competition. In particular doesn’t provide the ability to do protocol or message transformation. Needs to be augmented by a REST-capable ESB product for internal integration.
  • Portal always cloud hosted, which may be a hard barrier for some customers. Also limits ability to integrate with existing user credentials etc.
  • Rated towards the back of the pack by both Gartner and Forrester
  • Smaller company than most other players, which carries some commercial risk.  3scale secured $4.2m private funding in April 2013.

When would we use it?

  • Smaller customers for whom cost is the overriding factor
  • Customers looking for a simple solution to combine with an existing investment in internal REST-capable ESB technology, or green field customers who will expose REST APIs directly from back-end systems

As we mentioned last week, for the next few weeks we’re going to give you a whistle-stop tour of the key API management platforms we have our eye on. I should be clear: This is our view, not fact: Do your own due diligence before making any purchasing decisions! First up: Apigee.

Apigee are a well-established API Management Solutions provider (founded in 2004 and previously known as Sonoa Systems) and have a strong reputation within the marketplace with many (over 500) companies using their API Management Solutions including well-known brands such as Twitter, Nike, AT&T, eBay.

Apigee are positioning themselves as an all-encompassing Digital Services provider, branching out into providing commonly required supporting APIs for building e.g. social network features and push notifications etc. The Apigee platform itself is very capable, supporting both cloud and on-premises deployment.

Apigee recently closed $35m in funding to “meet demand as the businesses transform for the Digital World built on Apps, Data and APIs”. This funding came from BlackRock, Inc and Accenture.

Advantages:

  • Well established and respected brand in the API Management market place
  • Supports both Cloud on On-Premise solutions
  • Developer portal is good (using Drupal) which could be skinned to customers.
  • API-DN (distribution network), which moves policy enforcement out towards the network edge in a similar way to a CDN.
  • Very broad range of features, extending well beyond just an API gateway:
  • A free offering is available. Limitations (amongst others): Cloud only, portal is for non-production use only. No support for SSL. Reduced storage, reduced SLA.

Disadvantages:

  • Doesn’t have quite as good an enterprise security story as some of the other options in our opinion, which is key to some of our customers.
  • Message transformation, routing and protocol transformation more limited than some other options.
  • Apigee chose not to appear in both Gartner and Forrester reports, making it hard for enterprises to compare them to other offerings.

When would we use it?

  • Customer focussing on REST services (which should be everyone these days!)
  • Customer who specifically needs integrated billing services or BAAS features.
  • Relatively green field customer who doesn’t have a lot of gnarly internal integration to do.
  • Customer for whom a hardened appliance isn’t necessary.

Over the next few weeks, we’ll be sharing some of our findings from a review we conducted on four API management products, to help you work out which might work best for you and your organisation.

As part of this review, we found that they broadly fell into one of the two categories below:

  • API-native solutions: API-native solutions are useful for customers who don’t have a strong history of modular architecture or SOAP-based services. Some vendors are focusing on helping these types of companies by creating high-end developer portals; they also offer the infrastructure required to support these initiatives and provide easy to access and use data on consumption of APIs to cater for billing and reporting needs
  • SOA-native solutions: Vendors offering SOA-native solutions build upon the existing investments in SOAP / XML processing with the addition of new capabilities for RESTful service support, developer portals, and API-friendly security. This type of solution generally provides this capability through the integration of existing enterprise infrastructures via SOAP-to-REST protocol conversion. This integration capability can be very attractive to businesses, especially those who have invested heavily themselves in SOAP/ XML based services and architecture.

It’s worth considering which of these categories best aligns with the needs of your business. Are you a relative green field, happy to build brand new APIs, and adopt a ‘REST only’ (or at least JSON/HTTP only) approach, or do you have more complex needs, and want something with a bit more flexibility and pragmatism?

Keep an eye on the blog next week to understand which products fit into which categories, and what kinds of organisations they suit best.

Please state your position Photo: BNThermic via Police Helicopter, 14 March 2014

Please state your position
Photo: BNThermic via Police Helicopter, 14 March 2014

“What’s the difference between APIs and SOA?” A question with a million answers.

I’m not going to tell you I’m the holder of the One True Way here. I’m going to give you the Smart421 position.

To us, SOA was always about delivering easy to understand interfaces that expose business functionality from diverse underlying systems. We always felt this was as much about people as technology, and we never particularly bought into all the vendor hype that demanded true SOA required a massive stack of complicated tools and technologies, that (what a co-incidence!) only Vendor X could provide.

We’re simple straightforward folk, who like simple straightforward solutions.

Let’s take registries and repositories as an example. I once said to a colleague that one vendor’s product looked like it was designed by machines, for machines. It used language like Port Types, Bindings, Metadata, Ontologies etc. It was the dream of people who like to put acronyms on their CVs. What it didn’t help with at all from what I could see is helping the developers throughout your organisation discover services, and really understand quickly and easily what the service did, and how to use it.

The API movement has, by necessity, stripped a lot of the complexity away. Why? Because it turns out that if you are going to expose APIs to the outside world, where people have a choice about whether they should use your API or someone else’s, ease of use, and ease of discovery are critically important characteristics. Integrating with a REST(ish) API is, frankly, easier than integrating with a SOAP service. Discovering services and understanding them on a developer portal that is designed for humans is easier than poring over piles of WSDL in a freakishly complicated registry product.

If you’ve wondered why truly successful SOA initiatives are common as unicorns, here’s why: They often overcomplicate everything. Technology, processes, standards and the services themselves become a barrier to the very innovation they set out to enable.

Of course, nobody mandated SOAs have to be complicated. Nobody forced the world to adopt WS-*. We often tried to encourage customers to delay adopting complexity until the last responsible moment. That’s not to say WS-* weren’t useful. In the right contexts, they were, but they often came at the expense of accessibility and increased friction in adoption.

Unfortunately, the brutal reality is that for most people (or at least those who commission such initiatives), SOA as a term is connected indelibly with SOAP, ESBs, WS-* and rigid over-engineered change processes.

Sometimes, beautiful relationships don’t work out. Sometimes you just have to move on. So we have.

For us, APIs are the new SOA. What you might call SOA, we will refer to simply as internal APIs. On one level, this doesn’t change anything – it’s an emphasis thing. We still believe in the principles that underly SOA, and we’ll continue to build our integration on this basis. We know that APIs aren’t a silver bullet either. We’re certainly not saying “As long as it’s an API it’s good, and any old API will do”. There’s still plenty of scope to fail, plenty of mistakes to make (and to avoid repeating), and plenty of learning to do for our customers, for us, and for the entire API ecosystem.

But whether internal or external, we’ll focus on the same thing: Crafting APIs that are beautifully easy to understand, consume and change. We’ll fight the good fight to keep the standards and technologies we use mercifully simple, lest APIs suffer the same fate as SOA. We’ll try wherever possible to make the technology fade into the background.

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
Antoine de Saint-Exupéry

Share this post using the social icons below or via the short URL http://bit.ly/1ekeVNy

Please Rate and Like this Blog. Our Readers want to know what YOU think so please Comment.

I think anyone working in technology or digital industries can’t have helped but notice the hype around the API economy – it’s everywhere! You only have to look at the success that Amazon has had building a multi-billion dollar business with Amazon Web Services by providing a powerful API-based elements such as EC2.

SalesForce.com, Twitter and Google Maps have also benefited from opening up their APIs for others to consume and enhance and grow their business.

“So what if everyone is doing it, why should I?” – I think the question to ask is “What do I miss if I don’t take part in the API explosion?”.

Regardless of whether you’re a new or small business or a multi-national corporation the explosion of the API economy offers benefits for your business!

Whether this is by you discovering and consuming APIs that have already been developed so you don’t have to, providing key capabilities to enable your business, or providing you the opportunity to expose your APIs and turn them into a new revenue stream this is all within your reach!

API Management WordleFocussing on exposing and monetizing your APIs – how can you become part of this? Well, there are numerous API Management Solutions that are available in the market today (3Scale, Apigee, APIfy, Layer7, Mashery to name but a few) all with unique benefits with the solutions they offer. The choice of which API Management Solution to go with is one that anyone embarking on joining the API economy will face and the options and combinations available are numerous. How will people discover my APIs? How will you control access to your APIs? How will developers consume / try my APIs? What authentication is needed? Do you want and on-premise or cloud based solution?  How can you scale to meet the growing demand on your services?

These are just some of questions that you will need to address when thinking about your API strategy (regardless of if you are exposing the APIs internally within your business or to external consumers). At Smart421 we recognise that these are significant challenges and decisions that are needed in order to implement the right solution; we have looked at many of the API Management Solutions available and, given our expertise in systems integration, we are perfectly placed to help you with choosing and implementing the right solution to help you join the API economy explosion!

Please share using the social icons below or by using the short URL http://bit.ly/168BV01

Please Rate and Like this blog.  Our readers what to know YOUR opinion so please leave a Comment.

Following my last post, one of our clients reached out to me with a story about their own work in developing APIs.

The company had decided to build a new customer portal, and for pragmatic delivery reasons, decided to outsource the development of the portal to a 3rd party development shop. Inevitably though, the portal needed to talk to internal systems.

Rather than just hand out the technical documentation for their back end systems and punch holes in the firewall left right and centre, our client did the sensible thing and decided to expose some proper APIs for the portal developers to consume. They’d already built APIs (services) internally before, so knew what they were doing. Since these were only being used by a ‘friendly’ development partner rather than the great unwashed, they didn’t need a heavy duty API gateway product, and could get on with the task at hand in short order.

What they found was a surprise: Using a third party to deliver the portal seemed to make our client deliver better APIs than usual. This was despite the fact that they were using the same technologies as usual, and the same development teams The APIs were well documented, well structured and didn’t leak implementation details from their back-end processing systems.

This is a great example of Conway’s Law at work. If you’ve not heard of Conway’s Law before, go and read the article. It’s one of the most important lessons I’ve learnt, and it’s something that’s all too rarely understood and applied.

Some lessons I’ve taken away from this:

  1. Good IT architecture isn’t just a result of good technology and good people, it’s the direct result of the design of your organisation.
  2. Make sure the people building and consuming your APIs aren’t on the same team. The further apart they are in organisational terms, the more likely you are to deliver good quality APIs.
  3. If you’re building a website or portal, build it on top of your APIs, don’t just connect it straight to your back end. You could even get a good creative agency to do the work here – they’ll be used to consuming APIs, and it’ll force you to build APIs of the quality that e.g. mobile developers would expect.

Over the last few months, we’ve seen a real increase in interest from customers in creating public APIs. Regardless of industry, there’s a real buzz about creating new ways of driving value for end users by creating APIs.

The irony isn’t lost on us that for the last two decades (at least!) API was a term you wouldn’t dream of using with business people, but over the last couple of years we’ve started talking about the API Economy, how to market APIs and how to sell them.

APIs have been a mainstay of both startups and internet giants for a number of years now, with companies going through quite a journey to establish proper public APIs for their developer communities. What’s new I think is that the established blue chips are starting to see the size of the opportunity here.

The confluence (dare I say nexus?) of mobile, cloud, and the need to innovate are driving companies to think about how they deliver and manage APIs, safely and effectively.

But in a culture where integrating with third parties was mainly a bespoke, point to point, paperwork heavy experience, perhaps the biggest challenge for most will be fostering a community of developers who want to call the APIs in the first place, and aligning their interests with ours.

I’m really interested to talk to customers about their problems in this space, both technical and organisational. If you’d like a chat about this, drop me a line or send me a tweet.

Photo: Industrial backdrop by Pilarts  Dreamstime Stock Photos & Stock Free Images

Photo: Industrial backdrop by Pilarts Dreamstime Stock Photos & Stock Free Images

I’d like to propose a best practice for rolling out new features in a Service Oriented Architecture (SOA).

Traditionally, when we roll out a major new feature, we often end up causing a breaking change to the service. We’re then faced with a choice: (a) Force all our consumers to upgrade to the new version, and making all our consumers hate us, or (b) continue to support the old version of the service as well as the new, making only our own teams hate us. Suck it up, plan (b) is the better option, but try telling that to the guy having to patch fixes in three concurrent versions of a service.

Now, there are patterns that can help here (more on that another day), but they all still mean more work for everyone.

Also, when we first roll out a feature is exactly the moment we understand it least. We’ve got absolutely no idea how people will use it, nor whether it will even turn out to be useful. By baking the feature into a new major version of the service, we’re taking all our options away. The feature will be hard to remove if we decide it isn’t useful, and if we want to change how it works, we’re back into a major version upgrade again.

To my mind, good engineering is largely about keeping your options open. It’d be nice if we can try a new feature with a subset of consumers first, iterating quickly with just that subset, gradually adding more consumers as we get more confident.

Enter the Feature Flags pattern. Feature flags allow you to turn features on an off at a moment’s notice. At its most basic, a feature flag just turns a feature on or off for everyone at once, but the idea is often extended to allow turning on features for specific users, or collections of users. This allows you to roll out a new feature to consumers gradually, over an extended period.

So, here’s the proposal:

  • Allow consumers to pass a set of feature flags dictating which features they’d like enabled in the service.
  • Whenever you build a major new feature that would otherwise cause a breaking change, only enable it when the feature flag is passed.
  • If appropriate to your environment, control access to feature flags like you would to any other resource – e.g. you might want to restrict access in the early days to just a single consumer, making it easier to iterate.
  • Once we’re comfortable with a feature, it becomes publicly available – i.e. anyone can toggle the flag.
  • Every so often (e.g. once every couple of years), create a new major version of the service, refactoring it to include popular, battle tested features by default. Also, take this as an opportunity to clean out the cupboard and abandon any features that aren’t well used.

What do you think? Comments and thoughts very welcome…

 

Please remember to Rate and Like this post.  If you can, please leave a Comment.

Follow

Get every new post delivered to your Inbox.

Join 1,084 other followers