Gartner Blog Network

Libraries vs. Services

by Eric Knipp  |  March 20, 2013  |  2 Comments

While attending the Gartner BI Summit in Grapevine, TX yesterday I had a meeting with a client that made me facepalm a little.

The client in question was telling me about his need to educate his development staff in a number of critical areas, ranging from application lifecycle management, to data access patterns, to SOA governance, and on. The organization he works for is in the middle of a major hiring binge, and within the 200+ IT group there are few technologists with more than a year’s experience inside the company. This is a challenging situation, even when you can assume (as you should be able to) that most of your programmers know the difference between a library and a service! Many of the programmers in this organization prefer to create code libraries rather than services, and most of them don’t understand why they should build a service instead of a library. So, let’s get into that here.

In a nutshell: a library is shared code that you compile into your application. A service is a shared capability that you access from your application:

I am a (mostly) strong proponent of relying on services whenever possible, instead of building custom code libraries for inclusion in many programs. The agility, reuse, and transparency benefits of a service are just too hard to ignore. Having said that, I recognize that there are specific cases where creating libraries could be more appropriate:

  • When you’re building an application that will be deployed to a device with inconsistent network access (making remote service consumption unreliable)
  • When you’re building an application that will be hardened with wrapper technology for security reasons (and network access to remote services is seen as an unacceptable compromise)

A few more details that I quickly came up with which you might find worthwhile (let me know if you have any to add here):

Library Service
Characteristics Executes locally inside of your program Executes remotely outside of your program
Distributed/deployed with your program Exists independently of your program
Internal compilation dependency for your program External consumption dependency for your program
Cannot change unless you recompile/redeploy your program Versioned independently of your program
Instance used in your program is used only by your program Can be shared with many remote programs
Access to library routines cannot be mediated Access can be mediated for security, QoS, or other reasons
Access to library routines cannot be audited Access can be logged and audited by a mediator
Strengths Program cannot be inadvertently broken by a dependency change Many programs can benefit from service reuse and improvement
Programmers can easily understand all project dependencies Service mediation can provide many benefits
Compiled program is entirely self-contained Service-based design is more flexible to unanticipated changes
Weaknesses Library improvements can only be used at program recompilation Service oversubscription creates an availability bottleneck
Multiple versions of the same library can be used in many programs Service mediation is a black art to most programmers
Patterns of library consumption are not clearly visible at runtime Services may not be modeled with the right level of granularity for reuse

A final word.

Ever thought about being an analyst? You’re in luck! I am hiring two analysts in the UK (preferably the Greater London area) to join the Application Platform Strategy (APS) team. If you think you’d like to cover application design, development, and delivery for fun and profit, have a look at this link.

Category: applications  programming  

Eric Knipp
Managing Vice President
3 years at Gartner
15 years IT industry

Eric Knipp is a Managing Vice President in Gartner Research, where he focuses on Web and cloud application development methodologies and trends. Mr. Knipp is based in Dallas, Texas. Read Full Bio

Thoughts on Libraries vs. Services

  1. MDILLENB says:

    – white box from outside the application (other app knows the code behind)
    – no contract (just docu)
    – API with code (java, php, javascript, C#, etc)

    – black box from outside the application (other app doesnt know the code behind)
    – contractbased (WSDL, WADL, etc)
    – API with application protokol, dataformat (JMS, HTTP, XML, JSON, etc)

  2. Eric Knipp says:

    @MDILLENB: Thanks for the comment. You’re quite right with the above and I will add to my list. Thanks!


Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.