(Amplituhedron allows us to compute Quantum probabilities orders of magnitude faster than ever before)

APIs and Component as a Service – The dream achieved

Today, 10,000,000,000,000,000 API Calls/month are made in the cloud approximately.  This is a tremendous change in the way software is built.   We have achieved partly the dream of reusable software in the form of APIs and open source.   To me this is exciting stuff!!   When you look at the type of things available in APIs and open source projects today it is mind boggling how much is available and we are seeing that in the applications we get today in terms of amazing cross functionality from little effort.

For many years architects have promoted the practice of building component software.   The principal motivation for this has been the holy grail of software which is the desire to find some way initially to gain efficiency but eventually that all software might easily done by almost anybody simply by referring to higher and higher level abstractions.  Unfortunately, the complexity and lack of social aspects limited componentizations success like SOA.  Componentization by itself was not enough to achieve more and more reuse.

Today with the move to APIs as services in the cloud we tend to think of components as the pieces of code behind API(s) or multiple components stitched together to form a service with an API as its interface.   Frequently components are open source software projects or open software projects are components in a reusable service that has an API.   This API may be public or private, it may be in the cloud or hosted in an on-premise facility but the point is that the element of reusability is the API and open source components.

These new components have different requirements than CBSD (component based software development.)    I call this new component idea Component as a Service.    APIs are Component as a Service, but also any open source project or internal developed software can be a CaaS component.   Sure, there are technical subtleties to this but the overall movement is clearly to this model of componentization.   Today, we are offering components in the cloud and offering them as a service.  It is becoming wildly successful and you have to pay attention when designing any component whether being used entirely for internal use or explicitly for external use you should strive to make that component meet criteria I describe below.

Abbreviated history of  reuse

Sometimes reusable pieces have been incorporated into languages as underlying built-in capability or syntactic flourishes, annotations, libraries.  Languages in the early days of programming such as APL, SNOBOL contained lots of predefined functionality that greatly improved the speed to write programs that used those specific componentry.

Over time it was considered more important to have standard languages and the notion of libraries of functions become the place we put reusable code fragments.

This evolved into the notion of frameworks.   More recently with Java the possibility of having different languages which use an underlying common JAVA machine has allowed the creation of new special purpose languages without the deficits that specialized programming languages had in the past.   We see a surge of new programming languages such as SCALA, RUBY, GROOVY, PHP, …

Over the last 15 years the growth of open source movement has had an enormous impact on reusability, improving productivity and innovation in software engineering.  There is no standard way to package open source technology.  Yet, the ability to leverage open source depends greatly on the ability to incorporate it into your projects, so there is a lot of motivation by open source projects to foster reuse and simplify reuse.

We can see all these things are leading to the effort to package technology in reusable forms and make it easier to build software, more rapid to use it and proliferate its use by other software.

In this blog I am attempting to give you the framework to understand the requirements to build components that can be reused in services easily and be what I call cloud-native Components as a Service.

A CaaS (Component as a service) Definition

Historically,

1.  “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties”

The definition of component software has changed and is to some extent a nebulous concept.  Component based software engineering was started in the days of object oriented programming and has evolved over time.    This evolution reflects a growing understanding of how to reuse software.   For instance, a more practical definition I found:

• 2. fully documented
• 3.  thoroughly tested
  • robust – with comprehensive input-validity checking
  • able to pass back appropriate error messages or return codes
• 4. designed with an awareness that it will be put to unforeseen uses

Technically a component needs to meet certain qualifications to be Cloud-native or usable as Component as a Service (CaaS) including all of the above criteria (1-4 above).

Documentation and usage requirements

5.   Dependencies must be clearly articulated and the versions of those dependencies that it works with must be understood

6. A component API should reflect the way it will be used to make using the API as simple as possible.  If necessary multiple APIs should be available for multiple usage patterns or classes of users

7. All of the component API(s) should be documented and published in a social store where all users or potential users of the component can see it and all comments about it.  Private APIs should be visible only to private users but should be documented and published as well

8. APIs for a component should be changed as frequently as needed, sometimes very frequently.  Users should be made aware of all such changes suitably in advance and support for prior APIs should be supported for the time period appropriate for the usage

9. All of a components API(s) should be documented and should be possible to track usage through observations of the calls themselves as well as log files or event stream from the component 

10. Any internal data needed by a component should be accessible through the component and its interfaces public or private

Systemic requirements

11.  The component must isolate data from different subscribers in a well defined way

12.  A component should be able to be have multiple instances operating simultaneously

13.  A components fault tolerance capability should be well specified

14.  A component should be able to be packaged in a standard container like Docker

15. A component should conform to standards where applicable

16. Conform to standards for security or integrate with security systems in a well defined way

17.  test versions of components should be made available if needed for users to test it within their own functionality

18. SLAs for components in production as a service should be published or available

19.  A component should not depend on any specific network address, file system address, or other physical world dependency but should virtualize and allow injection of all such real world dependencies at time of invocation or instantiation. 

 Containers, Components and PaaS, the Cloud

Today, software is deployed instantly or near instantly using PaaS or DevOps software after it has passed testing.   Usually the way DevOps packages software is in a “container.”  The value of containers is to drastically in some cases simplify the installation of separate pieces and interdependencies of a service into a simple “unit” of composition which is easy to manage.    Containers usually have any specific instance dependencies “injected” into them at time of instantiation so that instances can be created on the fly anywhere without concern for physical constraints.

Containers also help isolate the possible errors a specific service can introduce into a system by limiting the damage to whatever is inside the container and no containers around it operating even on the same machine.

A component may be encapsulated inside multiple containers, for instance OSGi and Docker such that each container provides some protection or functionality.

API Management

Components should be designed to be managed by an API management system.  The value of this is clearly evident.

1.  Each components API is available for use and comment and improvement

2.  Each component can be tracked during usage if desired to see how it is being used and who is using it as well as for error resolution.

3.  If desired API management can be used to also govern and provide additional security for the component

4.  API management can facilitate version management and many of the requirements for components quality service described above

 

 

(Random picture I just coulnd’t resist.)

Summary

We are entering a new world of software development where software is composed largely of components in the form of open source or APIs that depend on other components.  The result is a blistering fast development of new powerful amazing applications, services and enhanced functionality at lower cost and faster time to market.   If we all follow the rules for building components as a service early on we can make the transition from the old world of slow development, bugs all the time, rarely fixed, living on the same software for years to this new world of rapid change and low cost, fast time to market.  It requires thinking of building or refactoring (taking old software and services and providing a new face) existing software in the enterprise as powerful Components as a Service APIs.

WSO2 is the only vendor I know of that provides a complete stack of platform 3.0,  SOA, Cloud and big data, mobile, social, API centric componentized CaaS software.    WSO2 has built its entire open source software stack on OSGi and multi-tenant component based model that can be taken in bite-size pieces and combined or used alone to build this new model of software development.  It really behooves you to consider looking at WSO2 at the minimum in terms of what are the requirements to build highly reusable cloud native component software even if you don’t use it yourself.   The approach of building truly componentized software that is open source and cloud native is brilliant approach to software development.

 

Other Articles to read on this topic:

Component-based_software_engineering

 a-simple-guide-to-cloud-computing-iaas-paas-saas-baas-dbaas-ipaas-idaas-apimaas

Computer_Programming/Component_based_software_development

put-it-in-the-store-the-new-paradigm-of-enterprise-social-asset-sharing-and-reuse-just-put-it-in-the-store

componentized-composable-platform-enterprise-quality-lincoln-logs