Introduction

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.

Functions-as-a-Service

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.

Fn Project

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.

Now that the server is running we can start building and eventually deploying the function. Fn jumpstarts the implementation by providing boilerplate files necessary for your function implementation and deployment. The sample provided in this article will be using the Go Programming language. To get started with Go, go to a new command window. Enter the command: fn init --runtime go (There are actually two dashes in front of runtime. See the screenshot below). There are a number of sources you may want to review to obtain an understanding and review of the Go programming language. I would recommend visiting Go here.

Execution of the command will generate a func.yaml, func.go, Gopkg.toml, and test.json file. An explanation of each file is provided below:

• func.yaml: This file contains metadata about your function and declares a number of properties.

• name: the name of the function. Matches the directory name.

• version: Automatically starting at 0.0.1

• runtime: the name of the runtime/language which was set based on the value set in - - runtime.

• entrypoint: the name of the executable to invoke when your function is called.

• format: The function uses JSON as its input/output method

• Gopkg.toml: The Go dep tool dependency management tool file which specifies all the dependencies for your function.

• test.json: A test file that is used to test your function, it defines an input and the output of the function.

• func.go: This file contains your actual Go function. It will default to a simple hello world example. You need to modify this function to include your own implementation.

The func.go file is a complete helloworld example. Before deploying the example, you will want to create an application. Applications define a namespace to organize functions and can contain configuration values that are shared across all functions in the defined application. You will first create an application to contain our functions.

With the application created you will now want to deploy the application to the Fn server. For the purposes of this example, the Docker registry is local. You can set an environment variable FN_REGISTRY to your Docker hub username, which would then prevent you from having to pass in the registry option.

The deploy statement completes multiple activities.
• Bumps the version number of the program
• Builds the program
• Pushes the image to the specified registry
• Updates the “route table” to associate a path with the image

The function can now be invoked using the http endpoint that was shown when you did the list of routes for the utilities application. You are free to choose your favorite REST enabled testing tool for the invocation.

curl -d ‘{“name”:”aname”}’ http://localhost:8080/r/utilities/helloworld

When the function is invoked the fn server looks up the function image name and tag associated with the route and has Docker run a container. If the required image is not already available locally then Docker will attempt to pull the image from the registry. A shortcut to curl is using `fn call`.

Monitoring

A dashboard is provided to monitor the applications and the functions that reside within that application. The dashboard must be installed locally if you want to view what has been deployed locally. The following command will install the Docker image of the dashboard, if it is not found locally, and then execute the dashboard.

docker run --rm -it --link fnserver:api -p 4000:4000 -e "FN_API_URL=http://api:8080" fnproject/ui

With the dashboard running, you are able to view the dashboard from a browser.

The dashboard shows the applications deployed and the metrics for the functions that are deployed. When you select the name of an application, such as utilities, then a new view shows the specifics of the functions deployed within that application.

Summary

The initial discussion of this post was about SOA and some of the shortcomings that many organizations faced when implementing a service-oriented architecture. Therefore, software vendors and the open-source community have been addressing ways to realize the benefits of SOA. You won’t hear organizations call this SOA 2.0, but the value of microservices and FaaS will definitely help organizations realize the benefits of scalable, bounded-context services.

The Fnproject.io discussed above demonstrated how easy it is to create a service, containerize it, and then to deploy to an Fn server.

Check back for future postings on how to integrate and leverage micro-services and FaaS in your PaaS and SaaS organization’s architecture.