According to Gartner’s Yefim V. Natis, VP & Fellow, a new enterprise architectural style is rising these days: Software-Defined Architecture (SDA).
During the Gartner webinar entitled Software-Defined Architecture: Application Design for Digital Business (account required), Natis took a look at the challenges that modern IT presents to software architects and some of the design principles that help architects create better applications that last longer. Among other things discussed during this webinar, Natis introduced this idea of SDA as a natural development in software architecture following previous styles starting with the monolithic one of the 70s as depicted in the next graphic taken from the webinar’s slides (PDF):
/filters:no_upscale()/news/2014/05/sda/en/resources/sda-1.png "image")
SDA follows on the path of Software-defined Networking (SDN), Software-defined Storage (SDS), and others, introduced by cloud computing, but this time it applies to whole stacks of software. The main idea is to introduce a level of virtualization between software producers and consumers. This boundary hides the internal details of a certain implementation, making it possible to change or replace the implementation without affecting the consumer. This process leads to the creation of two sets of APIs: an internal one for the producer’s use and an external one for the consumer as seen in the above graphic.
While the Inner API expresses a system’s organization in easily maintainable modules following standard architectural principles and comes on top of system optimizations for performance, the purpose of the Outer API is to make the Inner API easily and safely consumable by various external entities. Outer APIs offer a simplified view of the system and are optimized for network calls initiated over long distances.
To create SDA one starts with services, but they are not to be consumed directly. Instead, a gateway separates the services from consumers, creating a virtualization boundary between the two, as shown below:
/filters:no_upscale()/news/2014/05/sda/en/resources/sda-2.png "image")
SDA Gateway is responsible for the process of virtualizing the internal implementation resulting in the translation of the Inner APIs, the protocols and models used. This includes dealing with API versioning. The gateway covers a number of other functions such as security, routing, orchestration, etc. According to Natis, currently such a gateway is partially implemented by several products such as API Managers from Apigee and Mashery, API Gateway from Layer 7 or Vordel, ESBs that have expanded to include API management, and IPaaS (Integration Platform-as-a-Service) such as CastIron or Boomi.
Natis also recommends dealing with data security by creating a small number of services allowed to interact with raw data, thus concentrating the management and security to a smaller set of APIs reducing the footprint of possible security breaches.
We have interviewed Natis to find out a few more details on SDA.
InfoQ: I have not heard of SDA until now. Has this term been used by someone or have you coined it?
[YN] Yes, Gartner is introducing the term Software-defined Architecture. It’s new and we have not yet published reports on it. It’s underway.
InfoQ: Is SDA a natural step in the progress of software architecture from monolithic, 2-tier, etc.?
[YN] Yes, you can see SDA as virtualized or managed SOA. It’s a response to the proliferation of SOA interfaces (APIs) and continuing demand for more user-defined APIs. With SDA applications are virtualized and the outer APIs become decoupled from the inner APIs, allowing free creation of custom outer APIs without loss of application control.
InfoQ: What are the benefits of using SDA?
[YN] Virtualization of applications and application services; introduction of an intermediary (Gateway) between the outside world and the applications; an opportunity to add management, tracking, security, charging, activity monitoring, optimization, routing, integration, composition , orchestration, context injection and a lot of other added value between the external consumer of services and the applications that implement these services. One special possibility is to allow consumers to design their own APIs without adding risk to the underlying applications and data.
InfoQ: Could you provide some examples where SDA is being used?
[YN] SDA for applications is a new concept and there are not many significant implementations. Netflix API management is one proprietary example. But many uses in mainstream enterprises of integration brokers, API managers and API Gateways as well as SOA interface managers provide some degree of SDA capability. A full-fledged consistent use of SDA in application services management is several years away. It depends on technology, but no less – on the culture and discipline of the organizations that implement it.
Community comments
Service facade pattern?
by Christian Schneider,
Re: Service facade pattern?
by Abel Avram,
Re: Service facade pattern?
by Abel Avram,
Re: Service facade pattern?
by Christian Schneider,
Re: Service facade pattern?
by Abel Avram,
SOA and Software Defined Architecture
by Adrian Grigoriu,
Article Review
by Stephane Castellani,
Service facade pattern?
by Christian Schneider,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think this is not much more than the Service Facade pattern. The only difference is that there is also an inner service. I have seen this since at least 5 years for example to have technical services inside and more business like services for the outside. So where is this a new paradigm?
en.wikipedia.org/wiki/Facade_pattern
soapatterns.org/design_patterns/service_facade
Re: Service facade pattern?
by Abel Avram,
Your message is awaiting moderation. Thank you for participating in the discussion.
The service facade is a simple pattern that does API translation. Besides that, SDA includes a Gateway incorporating massive amounts of related services as described in the article.
Re: Service facade pattern?
by Abel Avram,
Your message is awaiting moderation. Thank you for participating in the discussion.
I post the following comment on behalf of Yefim Natis, the Gartner webinar author mentioned above:
Re: Service facade pattern?
by Christian Schneider,
Your message is awaiting moderation. Thank you for participating in the discussion.
Got it. So the main new thing is to have a gateway with rapid development functionality to easily create new outer services. I am not sure though how feasible this is. You mention that the advantage is that the outer services can be easily created an torn down. The problem I see here is that you never can easily tear down an API. APIs are long lived with a lot of emphasize on compatibility and management of the API. The only way I see to make them easy to change is to not publish them and instead only use them for one consumer. Is this what you intend?
Re: Service facade pattern?
by Abel Avram,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't remember saying that the Outer API is to be "easily created and torn down." I said
and also
which seems to me doable and desirable. What can be easily torn down is the inner implementation which is hidden to customers.
SOA and Software Defined Architecture
by Adrian Grigoriu,
Your message is awaiting moderation. Thank you for participating in the discussion.
To start with, the concept was since long called SDP (Service Delivery Platform) in the telecoms world. With SDP, the telecoms provided external customer applications APIs to internal services such as location, presence, calls, data connections... It existed even before that, in fact. The layer or gateway provided access control, QoS and security as well.
But SDP was, in fact, a tad more than that.
The concept already exists in SOA as well, where, for instance, mainframe interfaces are wrapped in SOA APIs. It is usually employed to hide existing applications interfaces under SOA APIs.
The reader should understand though that most SW manufacturers have adopted the SOA paradigm. And many are working to expose their services in the Cloud through simple APIs.
The problem is that the more public are the interfaces the more standardised they should be. Standardisation is what we need before using such interfaces. But then the Cloud growth may see to that.
For the time being, Cloud Brokers introduce a link in the services value chain to provide a uniform approach and the integration of Cloud Services. They do not call themselves SDAs providers though. And they introduce costs, delays...
The approach might be, rather than a physical gateway, a Cloud integration management suite, with which Cloud applications are compatible. This no SDA though.
Hence, there is nothing new here, except perhaps the term, SDA. But Gartner excels at new terms.
Article Review
by Stephane Castellani,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks for this very interesting article and for sharing vision in an always changing environment where strategic decisions need to be made for the next years. Btw, please note Vordel was acquired by Axway end 2012 and that the product is now called "Axway API Gateway"