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.
Let’s begin by going through a simple scenario of building a function, testing, and deploying it locally. The scenario is a simple one, but the example can serve as the basis for any type of function and can be extended to more complex functions. What is implemented in the function is not important, but rather how to package, deploy, and run the function on the FaaS platform.
In order to demonstrate the end-to-end flow, and not worry about an external cloud service, the sample will run the Fn server locally. This is a very powerful feature of the Fn project. What is tested locally will execute the same way in the cloud.
In order to get started follow the instructions to download the Fn CLI and start the Fn server. This information can be found at Fn Project. In order to execute Fn you need to have the following:
• Docker installed
• Docker Hub Account or another Docker compliant registry. You can even install the Docker container to run a registry locally. If you are planning to only do local development, testing, and deployment then this prerequisite is not a requirement.
The screenshot below shows the start of the local running Fn Server. The server listens on port 8080 and this cannot be changed if you are using the `fn start` command. To run on another port, you can start the server directly using `docker start` (see instructions here). Therefore, if you have other components listening on port 8080 then you will have to shut down that component. 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.