It wasn’t that many years ago that service-oriented architecture (SOA) was the hot, new, bleeding edge enterprise computing paradigm. Most organizations and vendors jumped on that bandwagon and everything became “service-oriented”. Organizations and vendors both made great claims about how SOA would revolutionize the way applications were built, the amount of reuse that would be achieved, and how application time to market would be greatly reduced. In addition, applications built with SOA technology were supposed to be easier to scale dynamically and those businesses that embraced SOA would see vast improvements in the relationships between IT and the business.
Unfortunately, the promises of SOA did not quite pan out across the board. Obviously, some organizations were successful, but far too many did not realize the promised benefits. There are many reasons why some succeeded and some failed but based on many years of first-hand experience building SOA applications and helping numerous customers with SOA-related challenges, here are three common reasons I noted those less than successful SOA projects:
1. Service Granularity. Organizations had a difficult time in defining what would be a service. Eventually, everything that was developed was referred to as a service. In a SOA environment, a service has versioning rules, is put under governance, and is normally categorized as intra-departmental, interdepartmental, or enterprise. To say that all developed code is a service would be overkill and it would mean tremendous overhead from an organizational and administrative perspective. Therefore, deeming everything a service normally means that none of this is put in place and the term service has no real SOA meaning.
2. Distributed Systems complexity. Developers had to be capable of understanding the complexities of distributed systems and the technologies involved with implementing distributed systems, think of transactions and security. Therefore, instead of focusing on implementing business logic a lot of effort was exhausted in worrying about the underlying technologies.
3. Scalability. The majority of “services” developed were deployed within application servers. This author is not saying application servers are bad but if one or two of the services needed to be scaled up or down it meant scaling the application servers. The scaling of application servers could be expensive, and most application servers cannot scale dynamically.
The discussion in recent years has shifted from SOA to Microservices to Serverless and Functions-as-a-Service (FaaS). It is this author’s opinion that these technologies are really the next phase of SOA, maybe even what SOA should have been in the first place. Microservices and FaaS deliver on many of the promises that SOA had originally marketed; dynamic scaling, focus on the business logic and not the underlying technologies, and bounding the context of the service. What follows will place emphasis on FaaS (Microservices will be discussed in follow-up blogs) and the open source Fn Project backed by Oracle.
A function is a simple piece of code that does one job, well. These functions are self-contained units of work. FaaS is a category of cloud services that raise the abstraction level so that developers focus on business logic and not think about servers, VMs, or other IaaS components. These functions are then deployed to the platform as containers.
The discussion which follows is about the Fn Project. Fn is a lightweight, open-source serverless compute platform, that can be deployed to any cloud and on-premise. It is simple, elegant, and extensible by design. This is an OSS project backed by Oracle. All development is in the open. Read the complete article here.
For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.