Download the Full Ebook and Access More Features - ebooknice.

com

(Ebook) Practical Spring Cloud Function:

Developing Cloud-Native Functions for Multi-Cloud
and Hybrid-Cloud Environments by Banu Parasuraman
ISBN 9781484289129, 1484289129
https://ebooknice.com/product/practical-spring-cloud-
function-developing-cloud-native-functions-for-multi-cloud-
and-hybrid-cloud-environments-47554112

OR CLICK HERE

DOWLOAD EBOOK

Download more ebook instantly today at https://ebooknice.com

 Instant digital products (PDF, ePub, MOBI) ready for you
Download now and discover formats that fit your needs...

Start reading on any device today!

(Ebook) Practical Spring Cloud Function: Developing Cloud-

Native Functions for Multi-Cloud and Hybrid-Cloud
Environments by Banu Parasuraman ISBN 9781484289136,
1484289137
https://ebooknice.com/product/practical-spring-cloud-function-
developing-cloud-native-functions-for-multi-cloud-and-hybrid-cloud-
environments-47554126
ebooknice.com

(Ebook) Cloud Native Java: Designing Resilient Systems

with Spring Boot, Spring Cloud, and Cloud Foundry by Long,
Josh, Bastani, Kenny ISBN 9781449374648, 1449374646
https://ebooknice.com/product/cloud-native-java-designing-resilient-
systems-with-spring-boot-spring-cloud-and-cloud-foundry-55586008

ebooknice.com

(Ebook) Spring Cloud Data Flow: Native Cloud Orchestration

Services for Microservice Applications on Modern Runtimes
by Felipe Gutierrez ISBN 9781484212400, 1484212401
https://ebooknice.com/product/spring-cloud-data-flow-native-cloud-
orchestration-services-for-microservice-applications-on-modern-
runtimes-24599766
ebooknice.com

(Ebook) Cloud Native Development with Google Cloud by

Daniel Vaughan

https://ebooknice.com/product/cloud-native-development-with-google-
cloud-53721370

ebooknice.com
(Ebook) Cloud Native Spring in Action by Thomas Vitale
ISBN 9781617298424, 1617298425

https://ebooknice.com/product/cloud-native-spring-in-action-47543946

ebooknice.com

(Ebook) Cloud Native Security Cookbook: Recipes for a

Secure Cloud by Josh Armitage ISBN 9781098106300,
109810630X
https://ebooknice.com/product/cloud-native-security-cookbook-recipes-
for-a-secure-cloud-43568432

ebooknice.com

(Ebook) Multi-Cloud Administration Guide: Manage and

optimize cloud resources across Azure, AWS, GCP, and
Alibaba Cloud. by Jeroen Mulder. ISBN 9789355515551,
9355515553
https://ebooknice.com/product/multi-cloud-administration-guide-manage-
and-optimize-cloud-resources-across-azure-aws-gcp-and-alibaba-
cloud-52198294
ebooknice.com

(Ebook) Cloud Native Infrastructure with Azure: Building

and Managing Cloud Native Applications by Nishant Singh &
Michael Kehoe ISBN 9781492090960, 1492090964
https://ebooknice.com/product/cloud-native-infrastructure-with-azure-
building-and-managing-cloud-native-applications-36653848

ebooknice.com

(Ebook) The Cloud Computing Journey: Design and deploy

resilient and secure multi-cloud systems with practical
guidance by Divit Gupta ISBN 9781805122289, 1805122282
https://ebooknice.com/product/the-cloud-computing-journey-design-and-
deploy-resilient-and-secure-multi-cloud-systems-with-practical-
guidance-58810386
ebooknice.com
Practical Spring
Cloud Function
Developing Cloud-Native Functions
for Multi-Cloud and Hybrid-Cloud
Environments
—
Banu Parasuraman
 Practical Spring
Cloud Function
Developing Cloud-Native
Functions for Multi-Cloud
and Hybrid-Cloud
Environments

Banu Parasuraman
Practical Spring Cloud Function: Developing Cloud-Native Functions for
Multi-Cloud and Hybrid-Cloud Environments
Banu Parasuraman
Frisco, TX, USA

ISBN-13 (pbk): 978-1-4842-8912-9 ISBN-13 (electronic): 978-1-4842-8913-6

https://doi.org/10.1007/978-1-4842-8913-6

Copyright © 2023 by Banu Parasuraman

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or
part of the material is concerned, specifically the rights of translation, reprinting, reuse of
illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way,
and transmission or information storage and retrieval, electronic adaptation, computer software,
or by similar or dissimilar methodology now known or hereafter developed.
Trademarked names, logos, and images may appear in this book. Rather than use a trademark
symbol with every occurrence of a trademarked name, logo, or image we use the names, logos,
and images only in an editorial fashion and to the benefit of the trademark owner, with no
intention of infringement of the trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if
they are not identified as such, is not to be taken as an expression of opinion as to whether or not
they are subject to proprietary rights.
While the advice and information in this book are believed to be true and accurate at the date of
publication, neither the authors nor the editors nor the publisher can accept any legal
responsibility for any errors or omissions that may be made. The publisher makes no warranty,
express or implied, with respect to the material contained herein.
Managing Director, Apress Media LLC: Welmoed Spahr
Acquisitions Editor: Steve Anglin
Development Editor: Laura Berendson
Coordinating Editor: Gryffin Winkler
Copy Editor: Kezia Endsley
Cover designed by eStudioCalamar
Cover image by Aamyr on Unsplash (www.unsplash.com)
Distributed to the book trade worldwide by Apress Media, LLC, 1 New York Plaza, New York, NY
10004, U.S.A. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail [email protected],
or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member
(owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance
Inc is a Delaware corporation.
For information on translations, please e-mail [email protected]; for
reprint, paperback, or audio rights, please e-mail [email protected].
Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook
versions and licenses are also available for most titles. For more information, reference our Print
and eBook Bulk Sales web page at http://www.apress.com/bulk-sales.
Any source code or other supplementary material referenced by the author in this book is
available to readers on GitHub (https://github.com/Apress). For more detailed information,
please visit http://www.apress.com/source-code.
Printed on acid-free paper
I would like to dedicate this book to my wife Vijaya and
my wonderful children Pooja and Deepika,
who stuck with me through the trials and
tribulations during the writing of this book.
I also dedicate this to my mom,
Kalpana Parasuraman.
Table of Contents
About the Author���������������������������������������������������������������������������������xi

About the Technical Reviewer�����������������������������������������������������������xiii

Acknowledgments������������������������������������������������������������������������������xv

Introduction��������������������������������������������������������������������������������������xvii

Chapter 1: Why Use Spring Cloud Function������������������������������������������1

1.1. Functions as a Service (FaaS)������������������������������������������������������������������������1
1.1.1. Implementation of an Enterprise Application����������������������������������������2
1.1.2. Migration ROI for a Portfolio of Application�������������������������������������������3
1.1.3. The Serverless Functions Concept��������������������������������������������������������4
1.1.4. Applying the Serverless Functions Concept to an Enterprise
Application���������������������������������������������������������������������������������������������4
1.2. Code Portability Issues�����������������������������������������������������������������������������������8
1.2.1. Serverless Container Portability Issue�������������������������������������������������10
1.3. Spring Cloud Function: Writing Once and Deploying to Any Cloud���������������11
1.4. Project Knative and Portable Serverless Containers������������������������������������13
1.4.1. Containers, Serverless Platforms, and Knative�����������������������������������15
1.4.2. What Is Knative?����������������������������������������������������������������������������������16
1.5. Sample Use Case: Payroll Application����������������������������������������������������������17
1.6. Spring Cloud Function Support��������������������������������������������������������������������19
1.6.1. Spring Cloud Function on AWS Lambda on AWS���������������������������������20
1.6.2. Spring Cloud Function on Knative and EKS on AWS����������������������������22
1.6.3. Spring Cloud Function on Cloud Functions on GCP�����������������������������23

v
Table of Contents

1.6.4. Spring Cloud Function on Knative and GKE on GCP�����������������������������24

1.6.5. Spring Cloud Function on Azure Functions on Azure���������������������������26
1.6.6. Spring Cloud Function on Knative and AKS on Azure��������������������������27
1.6.7. Spring Cloud Function on VMware Tanzu (TKG, PKS)���������������������������28
1.6.8. Spring Cloud Function on Red Hat OpenShift (OCP)����������������������������31
1.7. Summary�����������������������������������������������������������������������������������������������������32

Chapter 2: Getting Started with Spring Cloud Function����������������������33

2.1. Setting Up the Spring Boot and Spring Cloud Function Locally�������������������34
2.1.1. Step 1: Create the Spring Boot Scaffolding�����������������������������������������35
2.1.2. Step 2: Create the Employee Model����������������������������������������������������40
2.1.3. Step 3: Write the Consumer�����������������������������������������������������������������43
2.1.4. Step 4: Write the Supplier��������������������������������������������������������������������44
2.1.5. Step 5: Write the Function�������������������������������������������������������������������45
2.1.6. Step 6: Deploy and Run the Code Locally��������������������������������������������46
2.1.7. Step 7: Test the Function���������������������������������������������������������������������47
2.2. Setting Up Spring Cloud Function and AWS Lambda�����������������������������������49
2.3. Setting Up Spring Cloud Function and Google Cloud Functions�������������������59
2.4. Setting Up Spring Cloud Function Azure Functions��������������������������������������67
2.5. Setting Up Locally with Kubernetes and Knative and Spring Cloud
Function�������������������������������������������������������������������������������������������������������72
2.6. Setting Up AWS with EKS and Knative with Spring Cloud Function�������������82
2.7. Setting Up GCP with Cloud Run/GKE and Knative with Spring Cloud
Function�������������������������������������������������������������������������������������������������������89
2.8. Setting Up Azure with AKS and Knative with Spring Cloud Function�����������98
2.9. Setting Up VMware Tanzu TKG and Knative�����������������������������������������������102
2.10. Summary�������������������������������������������������������������������������������������������������106

vi
 Table of Contents

Chapter 3: CI/CD with Spring Cloud Function�����������������������������������107

3.1. GitHub Actions��������������������������������������������������������������������������������������������108
3.2. ArgoCD�������������������������������������������������������������������������������������������������������111
3.3. Building a Simple Example with Spring Cloud Function����������������������������120
3.4. Setting Up a CI/CD Pipeline to Deploy to a Target Platform������������������������122
3.5. Deploying to the Target Platform����������������������������������������������������������������124
3.5.1. Deploying to AWS Lambda�����������������������������������������������������������������124
3.6. Deploying to GCP Cloud Functions�������������������������������������������������������������129
3.7. Deploying to Azure Functions���������������������������������������������������������������������133
3.8. Deploying to Knative on Kubernetes����������������������������������������������������������138
3.9. Summary���������������������������������������������������������������������������������������������������147

Chapter 4: Building Event-Driven Data Pipelines with

Spring Cloud Function����������������������������������������������������������������������149
4.1. Data Event Pipelines����������������������������������������������������������������������������������149
4.1.1. Acquire Data��������������������������������������������������������������������������������������152
4.1.2. Store/Ingest Data�������������������������������������������������������������������������������152
4.1.3. Transform Data����������������������������������������������������������������������������������153
4.1.4. Load Data������������������������������������������������������������������������������������������153
4.1.5. Analyze Data��������������������������������������������������������������������������������������153
4.2. Spring Cloud Function and Spring Cloud Data Flow and
Spring Cloud Streams��������������������������������������������������������������������������������154
4.2.1. Spring Cloud Function and SCDF�������������������������������������������������������155
4.3. Spring Cloud Function and AWS Glue��������������������������������������������������������172
4.3.1. Step 1: Set Up Kinesis�����������������������������������������������������������������������173
4.3.2. Step 2: Set Up AWS Glue��������������������������������������������������������������������174
4.3.3. Step 3: Create a Function to Load Data into Kinesis��������������������������175
4.4. Spring Cloud Function and Google Cloud Dataflow������������������������������������185
4.5. Summary���������������������������������������������������������������������������������������������������197

vii
Table of Contents

Chapter 5: AI/ML Trained Serverless Endpoints with Spring

Cloud Function����������������������������������������������������������������������������������199
5.1. AI/ML in a Nutshell�������������������������������������������������������������������������������������199
5.1.1. Deciding Between Java and Python or Other Languages
for AI/ML��������������������������������������������������������������������������������������������206
5.2. Spring Framework and AI/ML��������������������������������������������������������������������209
5.3. Model Serving with Spring Cloud Function with DJL���������������������������������210
5.3.1. What Is DJL?��������������������������������������������������������������������������������������210
5.3.2. Spring Cloud Function with DJL��������������������������������������������������������218
5.4. Model Serving with Spring Cloud Function with Google Cloud
Functions and TensorFlow�������������������������������������������������������������������������225
5.4.1. TensorFlow����������������������������������������������������������������������������������������225
5.4.2. Example Model Training and Serving������������������������������������������������228
5.5. Model Serving with Spring Cloud Function with AWS Lambda and
TensorFlow�������������������������������������������������������������������������������������������������241
5.6. Spring Cloud Function with AWS SageMaker or AI/ML������������������������������243
5.7. Summary���������������������������������������������������������������������������������������������������251

Chapter 6: Spring Cloud Function and IoT����������������������������������������253

6.1. The State of IoT������������������������������������������������������������������������������������������253
6.1.1. Example Spring Implementation�������������������������������������������������������255
6.1.2. An Argument for Serverless Functions On-Premises������������������������256
6.2. Spring Cloud Function on the Cloud with AWS IoT�������������������������������������257
6.3. Spring Cloud Function on the Cloud with Azure IoT�����������������������������������270
6.3.1. Azure IoT Edge Device�����������������������������������������������������������������������271
6.3.2. Azure IoT Hub������������������������������������������������������������������������������������271
6.4. Spring Cloud Function on Azure IoT Edge��������������������������������������������������272
6.5. Spring Cloud Function On-Premises with IoT Gateway on a
SaaS Provider (SmartSense)����������������������������������������������������������������������280
6.6. Summary���������������������������������������������������������������������������������������������������283

viii
 Table of Contents

Chapter 7: Industry-Specific Examples with

Spring Cloud Function����������������������������������������������������������������������285
7.1. Oil/Natural Gas Pipeline Tracking with Spring Cloud Function and IOT������285
7.1.1. Sensors����������������������������������������������������������������������������������������������287
7.1.2. IoT Gateway���������������������������������������������������������������������������������������287
7.1.3. IBM Cloud Functions��������������������������������������������������������������������������288
7.1.4. IBM Watson IoT Platform�������������������������������������������������������������������288
7.1.5. IBM Watson IoT Platform: Message Gateway������������������������������������288
7.1.6. IBM Event Streams����������������������������������������������������������������������������289
7.1.7. IBM Cloudant DB��������������������������������������������������������������������������������289
7.2. Enabling Healthcare with Spring Cloud Function and Big
Data Pipelines��������������������������������������������������������������������������������������������308
7.3. Conversational AI in Retail Using Spring Cloud Function���������������������������311
7.3.1. Components of Conversational AI Solutions��������������������������������������314
7.3.2. Watson Assistant Webhooks and Spring Cloud Function�������������������315
7.3.3. Implementing the Watson Assistant with Spring Cloud Function������316
7.4. Summary���������������������������������������������������������������������������������������������������333

Index�������������������������������������������������������������������������������������������������335

ix
About the Author
Banu Parasuraman is a cloud native
technologist and a Customer Success Manager
(CSM) at IBM, with over 30 years of experience
in the IT industry. He provides expert advice
to clients who are looking to move to the cloud
or implement cloud-native platforms such
as Kubernetes, Cloud Foundry, and the like.
He has engaged over 25 select companies
spread across different sectors (including
retail, healthcare, logistics, banking, manufacturing, automotive, oil
and gas, pharmaceuticals, and media and entertainment) in the United
States, Europe, and Asia. He is experienced in most of the popular cloud
platforms, including VMware VCF, Pivotal PCF, IBM OCP, Google GCP,
Amazon AWS, and Microsoft Azure. Banu has taken part in external
speaking engagements targeted at CXOs and engineers, including at
VMworld, SpringOne, Spring Days, and Spring Developer Forum Meetups.
His internal speaking engagements include developer workshops on
cloud-native architecture and development, customer workshops on
Pivotal Cloud Foundry, and enabling cloud-native sales plays and
strategies for sales and teams. Lastly, Banu has numerous blogs on
platforms such as Medium and LinkedIn, where he promotes the adoption
of cloud-native architecture.

xi
About the Technical Reviewer
Manuel Jordan Elera is an autodidactic
developer and researcher who enjoys learning
new technologies for his own experiments and
creating new integrations. Manuel won the
Springy Award 2013 Community Champion
and Spring Champion. In his little free time,
he reads the Bible and composes music on his
guitar. Manuel is known as dr_pompeii. He
has tech-reviewed numerous books, including
Pro Spring MVC with Webflux (Apress, 2020),
Pro Spring Boot 2 (Apress, 2019), Rapid Java Persistence and Microservices
(Apress, 2019), Java Language Features (Apress, 2018), Spring Boot 2
Recipes (Apress, 2018), and Java APIs, Extensions, and Libraries (Apress,
2018). You can read his detailed tutorials on Spring technologies and
contact him through his blog at www.manueljordanelera.blogspot.com.
You can follow Manuel on his Twitter account, @dr_pompeii.

xiii
Acknowledgments
It has been a great privilege to write this book and help you understand
real-world implementations of Spring Cloud Function. Thank you for
reading it.
After my presentation at SpringOne 2020, I received a message on
LinkedIn from Steve Anglin at Apress. Steve asked me if I would be willing
to write a book about Spring Cloud Function. I was a bit hesitant at first,
given that I was occupied with many client engagements, which were
taking up most of my work hours. I was worried that I would not do the
subject justice, due to my preoccupation with my clients. But after a long
contemplation and a heartfelt discussion with my family, I decided to
take it on.
I want to thank Steve Anglin, Associate Editorial Director, for reaching
out to me and providing me this opportunity to write a book on Spring
Cloud Function.
Mark Powers, the Editorial Operations Manager, was instrumental
in helping me bring this book to close. With his incessant prodding and
nudging, he helped me reached the finish line. Thanks, Mark.
Manuel Jordan, the technical reviewer, was immensely helpful. His
comments kept me honest and prevented me from cutting corners. He
helped improve the quality of the solutions that I present in this book.
Thanks, Manuel.
I also want to thank Nirmal Selvaraj and others at Apress, who worked
to bring this book to fruition.
This book would not be possible without the help of my wife Vijaya and
daughters Pooja and Deepika, who provided the much-needed emotional
support through this journey.

xv
Introduction
I entered the field of Information Technology (IT) 25 years ago, after
spending time in sales and marketing. I was an average programmer and
was never into hardcore programming. During my early life in IT, I worked
as part of a team that built a baseball simulator for the Detroit Tigers. I
helped build a video capture driver for that simulator using C++. Even
though this was a great project with a lot of visibility, it was never my real
passion to be a hard-core programmer.
I soon gravitated toward solution architecture. This seemed to
perfectly tie my marketing skills to my technology skills. I began looking
at solutions from a marketing lens. This approach formed the basis for
writing this book. Because, what good is a technology if we do not know
how to apply it in real life?
Functional programming was an emerging technology. Cloud
providers such as AWS, Google, and Azure created serverless
environments, with innovations such as Firecracker virtualization
techniques, that allowed infrastructure to scale down to zero. This allowed
customers to derive huge cost savings by not paying for resources that were
not in use and subscribing to a pay-per-use model.
Initially, development of these functions that run on serverless
environments were built on either NodeJS or Python. These functions
were also vendor-specific. Spring.io developed the Spring Cloud Function
framework, which allowed the functions to run in a cloud-agnostic
environment. The focus was on the “write once, deploy anywhere”
concept. This was a game changer in the cloud functions world.

xvii
Introduction

Prior to writing this book, I was a staunch evangelist of Pivotal Cloud

Foundry and Kubernetes. I promoted writing code that was portable.
When Knative came into being in 2018 as a joint effort between IBM and
Google, I was excited. Knative was designed as a serverless infrastructure
on top of Kubernetes and made the serverless infrastructure portable.
Combining the power and portability of Spring Cloud Function and
Knative, you have a true portable system with zero scale-down capabilities.
This was something that I wanted to write and evangelize about. But I
felt that writing about the technology and how it worked would not be that
exciting. I wanted to write about how people could use this technology in
the real world.
In this book, you will see how to program and deploy real-life
examples using Spring Cloud Function. It starts with examples of writing
code and deploying to AWS Lambda, Google Cloud Function, and
Azure Function serverless environments. It then introduces you to the
Knative on Kubernetes environment. Writing code and deploying is not
enough. Automating the deployment is key in large-scale, distributed
environments. You also see how to automate the CI/CD pipeline through
examples.
This books also takes you into the world of data pipelines, AI/ML,
and IoT. This book finishes up with real-world examples in oil and gas
(IoT), manufacturing (IoT), and conversational AI (retail). This book
touches on AWS, the Google Cloud Platform (GCP), Azure, IBM Cloud, and
VMware Tanzu.
The code for these projects is provided on GitHub at https://
github.com/banup-kubeforce. It is also available at github.com/apress/
practical-spring-cloud-function. This allows you to get up to speed on
the technologies. So, after completing this book, you will have hands-on
experience with AI/ML, IoT, data pipelines, CI/CD, and of course Spring
Cloud Function.
I hope you enjoy reading and coding this book.

xviii
CHAPTER 1

Why Use Spring

Cloud Function
This chapter explores Spring Cloud Function using a sample use case—an
HRM (Human Resources Management) system. The focus is on systems
that reside in an enterprise. The chapter touches on the FaaS (Functions
as a Service) concept and explains how it is gaining momentum in the
enterprise. The chapter also digs deeper into its implementations in the
cloud. You will learn about some of the portability issues present at the
code and container level and read about concepts such as Knative on
Kubernetes, which includes container portability. You will also learn about
some high-level implementations of Spring Cloud Function on AWS, GCP,
Azure, VMware Tanzu, and Red Hat OpenShift.

1.1. Functions as a Service (FaaS)

FaaS is a revolutionary technology. It is a great boon for developers and
businesses. FaaS allows businesses to adapt to rapidly changing business
needs by enabling their development teams to develop products and
features at a “high” velocity, thereby improving their Mean Time To Market
(MTTM). Developers can develop functions without worrying about
setting up, configuring, or maintaining the underlying infrastructure. FaaS
models are also designed to use just the right quantity of infrastructure and

© Banu Parasuraman 2023 1

B. Parasuraman, Practical Spring Cloud Function,
https://doi.org/10.1007/978-1-4842-8913-6_1
Chapter 1 Why Use Spring Cloud Function

compute time. They also can be scaled to fit exact demand, by focusing on
billing for the number of invocations as compared to billing for uptime.
FaaS has two parts, as shown in Figure 1-1.

• The function code encapsulates the business logic

in any language, such as Java, C#, Python, Node,
and so on.

• The underlying container hosts an application server

and an operating system.

Figure 1-1. FaaS component architecture

1.1.1. Implementation
of an Enterprise Application
Imagine all the infrastructure needed to run a single payroll application
on the cloud. This application may consume only 16GB of RAM and eight
vCPUs, but you are charged continuously for the entire duration that the
application is active. Using a simple AWS pricing formula, this works out
to around $1,000 per year. This cost is for the whole time the application

2
 Chapter 1 Why Use Spring Cloud Function

is hosted and active, regardless of use. Of course, you can cost-justify

it through a TCO (Total Cost of Ownership) calculation, which helps
you determine how your application can bring in revenue or value that
compensates for the expense. This revenue-generation model is more
suitable to applications that generate revenue for the company, such as
an ecommerce site. It is more difficult to prove the value that a supporting
application, running in the backend of an enterprise, brings to a company.

1.1.2. Migration ROI for a Portfolio of Application

The value equation gets more complex if you plan to migrate an extensive
portfolio of apps in your enterprise.
Let’s for a moment assume, as a CTO or CIO of a company, you have a
portfolio of about one thousand applications that you plan on migrating to
the cloud. The key factors to consider, among the many, include:

• What is the current infrastructure supporting the apps?

• What is the utilization of these apps?

The utilization of apps is an essential factor in determining the value of

the application. Consider this—after analyzing the utilization of apps, you
find that this portfolio includes the following distribution:
• 10% with 80% utilization

• 40% with 50% utilization

• 50% with 20% utilization

If you calculate the billing cost using an AWS cost calculator, you see
that you will spend $1 million per year. This spend is for applications
that are critical and highly utilized, as well as for applications that are
minimally utilized. This cost is due to the fact that the cloud providers
charge for the entire duration the application is active and consuming
the infrastructure. The key here is that the infrastructure is fully allocated

3
Chapter 1 Why Use Spring Cloud Function

for the application’s life. Imagine how much you could save if the
infrastructure was allocated only for the duration that the application
was active and serving. This would be a great cost and resource saving
approach. Cloud providers have thought through this because they also
faced the pressure of finite infrastructure and considered the time needed
to provision additional infrastructure.

1.1.3. The Serverless Functions Concept

To work around the problem of finite infrastructure utilization, AWS
created Lambda serverless functions. This was a genius invention.
Subscribers to this service pay only for the time the application is invoked.
The infrastructure is unallocated when it is not invoked. This way, AWS can
save on infrastructure by repurposing the infrastructure for other needy
applications while transferring the cost savings to the customer. This is a
win-win. It’s worth considering whether you can apply this same approach
to all the enterprise applications in your company today. You would be
able to save a lot of money. Also, if you were to bring this technology to the
datacenter, you would be able to reap the benefits that AWS realized. Isn’t
this wonderful?

1.1.4. Applying the Serverless Functions

Concept to an Enterprise Application
Let’s dig deeper into the concept of functions and how AWS realizes the
magic of infrastructure savings. Functions are tiny code pieces with a
single input and a single output, and a processing layer (a predicate) acting
as the glue. Compare this to enterprise apps, which are designed to do
many things. Take a simple payroll system, for example. A payroll system
has multiple input interfaces and multiple output interfaces. Here are
some of those interfaces:

4
 Chapter 1 Why Use Spring Cloud Function

• Timecard system to get the hours employees worked

in a month

• Performance evaluation system

• Peer feedback system

• Inflation adjustment calculator system

• The outgoing interface to the IRS

• The outgoing interface to the medical insurance

provider

• An outgoing interface to the internal web portal where

employees can download their paystubs

Running this payroll application is not trivial. I have seen such a

payroll system use the following:

• Fourteen dedicated middleware application servers

• Two RDBMS database stores

• Two integration tools such as message queues and FTP

• Four dedicated bare-metal servers, with each server

configured with 128GB RAM, 32 CPUs, 4TB of HDD,
10TB of vSAN, and the like

The key factor in determining whether this application can be hosted

on a serverless functions infrastructure like Lambda is the time it takes for
the application to boot up (the startup time or cold start) and the time it
takes for the application to shut down (the shutdown time). The faster the
startup and shutdown times, the larger the cost savings.
It is also important that these times be quick so that they don’t cause
disruptions. If you were to research the startup times for large enterprise
applications like the payroll application, you would find that it is not
pretty. An average startup time is around 15 minutes for all components to

5
Chapter 1 Why Use Spring Cloud Function

come up and another 15 minutes for the application to come down. This
would not fly. Imagine if you deployed this application to an AWS Lambda
serverless function. Thirty minutes of downtime for each invocation?
This will not work. Your users would abandon the application entirely. As
you can see, large applications cannot benefit from resource release and
resource reassignment because they take a long time to start up and shut
down, which would impact the general operation of the application.
Can you make this large payroll application behave in an expected way
for serverless functions? The answer is yes. A lot of refactoring is required,
but it can be done.

Serverless Function in the Cloud

All cloud providers have now incorporated the serverless functions into
their infrastructure offerings. AWS has Lambda Functions, Google has
Cloud Functions, and Azure has Azure Functions. These providers, in
the quest for making their customers captive, made sure to introduce
proprietary elements into their environments. The two components that
are essential to run the functions are:

• Serverless function code that serves the functions

• Serverless infrastructure (containers) that supports

the code

 hy Is It Important for Serverless Functions

W
to be Non-­Proprietary?
Enterprises are gravitating toward a multi-cloud, hybrid-cloud approach
to their cloud strategy. As you can see in Figure 1-2, the survey of 3,000
global respondents indicated that 76 percent already work in a multi-cloud
environment. This means they are not bound to one single cloud provider.
The adoption of a multi-cloud strategy alleviates the risk of vendor lock-in.

6
 Chapter 1 Why Use Spring Cloud Function

Figure 1-2. Multi-cloud adoption report

Source: https://info.flexera.com/CM-REPORT-State-of-the-
Cloud?lead_source=Website%20Visitor&id=Blog

In a multi-cloud world, it is essential that enterprises subscribe to

services that can be easily ported between clouds. This is especially
important for commodity services.
FaaS, or serverless functions, have of late become a commodity with all
the providers having some services around FaaS. It is therefore imperative
that FaaS containers not have proprietary code.
Serverless functions become portable when they do not use
proprietary code. Portable serverless functions allow for workload mobility
across clouds. If, for instance, AWS Lambda functions are costly and Azure
Functions are cheap, enterprises can avail the cost savings and move that
Lambda workload to Azure Functions with very little effort.
The subsequent sections discuss in detail these portability issues and
explain how you can solve them.

7
Chapter 1 Why Use Spring Cloud Function

1.2. Code Portability Issues

Listing 1-1 shows the sample AWS Lambda code written in Java. This
code was generated using the AWS SAM (Serverless Application Model)
template. When observing the code, you can see that the AWS-specific
library references and method calls bind the code to AWS. It is not much,
but it is potent. In an enterprise, you typically have hundreds if not
thousands of pieces of code that you must refactor if you want to move this
type of code to another cloud provider. This is a costly affair.

8
 Chapter 1 Why Use Spring Cloud Function

Listing 1-1. Sample Code Using the AWS SAM Framework

The following section explores the portability of the underlying

serverless container, which impacts how multi-cloud migrations are
conducted.

9
Chapter 1 Why Use Spring Cloud Function

1.2.1. Serverless Container Portability Issue

What about Lambda’s underlying serverless framework? Is it portable?
If you deep dive into AWS Lambda, the virtualization technology used
is Firecracker. Firecracker uses KVM (a kernel-based virtual machine)
to create and manage microVMs. You can find more information on
Firecracker at https://aws.amazon.com/blogs/aws/firecracker-
lightweight-virtualization-for-serverless-computing/.
The minimalist design principle that Firecracker is built on allows
for fast startup and shutdown times. Google Cloud Functions, on the
other hand, use gVisor and are not compatible with Firecracker. gVisor is
an application kernel for containers. More information can be found at
https://github.com/google/gvisor.
Azure Functions take a totally different approach of using the
PaaS offering app service as their base. So, you can see that the major
cloud providers use their own frameworks for the managing functions’
containers. This makes it difficult for functions to move between clouds
in a multi-cloud environment. This portability issue becomes more
pronounced due to the lack of portability at the container level.

Figure 1-3. Serverless architecture comparison

You can see that the code and containers both differ from the provider
and are not easily portable.

10
 Chapter 1 Why Use Spring Cloud Function

In the discussions so far, you have seen the following issues related
to FaaS:

• Portability of code

• Portability of the serverless container

• Cold start of the serverless environment

How do you solve these issues?

Enter Spring Cloud Function and Knative. Spring Cloud Function
addresses function code portability, and Knative addresses container
portability.
Information on Spring Cloud Function is available at https://spring.
io/projects/spring-cloud-function, and information about Knative is
available at https://knative.dev/docs/.
The following sections deep dive into each of these topics.

1.3. Spring Cloud Function: Writing Once

and Deploying to Any Cloud
As you learned from the earlier discussion, writing functions for AWS
Lambda, Google Cloud Functions, or Azure Functions is a proprietary
activity. You have to write code specific to a hyperscaler. Hyperscalers
refer to large-scale cloud providers like AWS, Google, or Azure, who have a
complete mix of hardware and facilities that can scale to 1000s of servers.
This is not bad if your strategy is to have a strong single hyperscaler
relationship, but over time, when your strategy changes to a hybrid cloud
or multi-cloud, you may have to rethink your approach.
A hybrid cloud comprises a private cloud and a public cloud
and is managed as one entity. Multi-cloud includes more than
one public cloud and does not have a private cloud component.

11
Chapter 1 Why Use Spring Cloud Function

This is where the Spring Cloud Function comes in. The Spring.io team
started the Spring Cloud Function project with the following goals:

• Promote the implementation of business logic via

functions.

• Decouple the development lifecycle of business logic

from any specific runtime target so that the same code
can run as a web endpoint, a stream processor, or a task.

• Support a uniform programming model across

serverless providers, as well as the ability to run
standalone (locally or in a PaaS).

• Enable Spring Boot features (auto-configuration,

dependency injection, metrics) on serverless providers.

Source: https://spring.io/projects/spring-cloud-function
The key goals are decoupling from a specific runtime and supporting a
uniform programming model across serverless providers.
Here’s how these goals are achieved:

• Using Spring Boot

• Wrapper beans for Function<T, R> (Predicate),

Consumer<T>, and Supplier<T>

• Packaging functions for deployments to target

platforms such as AWS Lambda, Azure Functions,
Google Cloud Functions, and Knative using adapters

• Another exciting aspect of Spring Cloud Function is that

it enables functions to be executed locally. This allows
developers to unit test without deploying to the cloud

Figures 1-4 and 1-5 show how you can deploy Spring Cloud Function.
When Spring Cloud Function is bundled with specific libraries, it can be
deployed to AWS Lambda, Google Cloud Functions, or Azure Functions.

12
 Chapter 1 Why Use Spring Cloud Function

Figure 1-4. Deploying Spring Cloud Function directly to FaaS

environments provided by the cloud providers

Figure 1-5. Deploying Spring Cloud Function on Knative serverless

configured on Kubernetes environments provided by the cloud
providers
When Spring Cloud Function is containerized on Knative, it can
be deployed to any Kubernetes offering, whether on the cloud or on-­
premises. This is the preferred way to deploy it on hybrid and multi-cloud
environments.

1.4. Project Knative and Portable

Serverless Containers
Having a portable serverless container is also important. This minimizes
the complexity and time required to move between cloud providers.
Moving between cloud providers to take advantage of discounted pricing
goes a long way toward saving costs. One methodology used is called
cloud bursting (Figure 1-6). Cloud bursting compensates for the lack
of infrastructure on-premises by adding resources to the cloud. This is
usually a feature of a hybrid cloud.

13
Chapter 1 Why Use Spring Cloud Function

Figure 1-6. Cloud bursting

Figure 1-6 shows that, to compensate for the lack of resources in a

private cloud during a traffic spike, resources are allocated to the public
cloud where the traffic is routed. When the traffic spike goes down, the
public cloud resources are removed. This allows for targeted use of costs
and resources—that is, it uses additional resources only during the traffic
spike period. The burst of activity during an eCommerce event like Cyber
Monday is a great example of a traffic spike.
This cannot be easily achieved with just a portable code. You need
containers that are also portable. This way, containers can be moved
across cloud boundaries to accommodate traffic spikes. In Figure 1-6,
you can see that VMs from VMware are used as containers. Since the VMs
hosted in the datacenter and hosted in the cloud are similar in construct,
cloud bursting is possible.
Applying this to Functions as a Service, you need a new way to make
the underlying serverless containers portable.
One such revolutionary approach in the cloud function world is
Knative. The next section dives deep into Knative.

14
 Chapter 1 Why Use Spring Cloud Function

1.4.1. Containers, Serverless Platforms,

and Knative
What was the need for containers /serverless platforms?
Over the course of the evolution of IT, there has been a need for
secure isolation of running processes. In the early 90’s, chroot jail-based
isolation allowed developers to create and host a virtualized copy of the
software system. In 2008 Linux Containers (LXC) was introduced which
gave the developers a virtualized environment. In 2011 Cloud Foundry
introduced the concept of a container, and with Warden in 2019 container
orchestration became a reality. Docker, introduced in 2013, provided
containers that can host any operating system. Kubernetes, introduced in
2014, provided the capability to orchestrate containers based on Docker.
Finally, Knative, introduced in 2018, extended Kubernetes to enable
serverless workloads to run on Kubernetes clusters.
Serverless workloads (Knative) grew out of the need to help developers
rapidly create and deploy applications without worrying about the
underlying infrastructure. The serverless computing model takes care of
provisioning, management, scheduling, and patching and allows cloud
providers to develop the “pay only for resources used” model.
With Knative, you can create portable serverless containers that run
on any Kubernetes environment. This allows for FaaS to be portable in a
multi-cloud or hybrid-cloud environment.
Besides making developers more productive, the serverless
environment offers faster deploys (see Figure 1-7). Developers can use
the “fail fast and fail often” model and spin up or spin down code and
infrastructure faster, which helps drive rapid innovation.

15
Chapter 1 Why Use Spring Cloud Function

Figure 1-7. Serverless deploys the quickest

1.4.2. What Is Knative?
Knative is an extension of Kubernetes that enables serverless workloads
to run on Kubernetes clusters. Working with Kubernetes is a pain. The
amount of tooling that is required to help developers move their code from
the IDE to Kubernetes defeats the purpose of the agility that Kubernetes
professes to bring to the environment. Knative automates the process of
build packages and deploying to Kubernetes by provider operators that are
native to Kubernetes. Hence, the names “K” and “Native”.
Knative has two main components:

• Serving: Provides components that enable rapid

deployment of serverless containers, autoscaling, and
point-in-time snapshots

• Eventing: Helps developers use event-driven

architecture by providing tools to route events from
producers to subscribers/sinks

You can read more about Knative at https://Knative.dev/docs.

16
 Chapter 1 Why Use Spring Cloud Function

1.5. Sample Use Case: Payroll Application

Let’s look at how you can apply serverless functions to a real-life example.
We introduced the payroll application in the beginning of the chapter,
we’ll now build on it. Consider a payroll application with the configuration
shown in Figure 1-8.

Figure 1-8. Payroll application components

Figure 1-9 shows the configuration.

17
Chapter 1 Why Use Spring Cloud Function

Figure 1-9. Payroll application flow

Translating this flow diagram into an actual implementation that can

be deployed in a corporate datacenter results in Figure 1-10. You see that
the functions are developed as REST APIs that are executed in batch mode.
The REST APIs expose SAP ECC payroll modules. These REST APIs are
run as batch jobs every 15 days. The databases are hosted on Oracle, and
integrations are exposed using IBM API Connect (APIC). Note that this is
not an on-demand process and can consume a lot of resources when idle.
These REST APIs cannot be easily shut down and started up because a
typical time for booting up a SAP NetWeaver component can be anywhere
from 2 to 15 minutes, depending on the JVM configuration. These
application components must be running constantly to keep the payroll
application from breaking down.

18
 Chapter 1 Why Use Spring Cloud Function

Figure 1-10. Current payroll architecture

Using this use case, the following sections explore how you can
leverage Spring Cloud Function to modernize and transform this
application into a highly efficient, scalable, and portable system.

1.6. Spring Cloud Function Support

The Spring Cloud Function is supported in almost all cloud offerings, as
shown in Table 1-1.

19
Chapter 1 Why Use Spring Cloud Function

Table 1-1. Spring Cloud Function Support Among Cloud Providers

AWS Azure Google IBM Cloud On-Premises

Lambda Azure Cloud IBM Functions Tanzu with Knative

Functions Functions
EKS with AKS with GKE with Tanzu with OpenShift with
Knative Knative Knative Knative Knative
Fargate with ARO with OpenShift OpenShift with Any Kubernetes
Knative Knative with Knative Knative offering with Knative
ROSA with Tanzu with Tanzu with IBM Kubernetes
Knative Knative Knative with Knative
Tanzu with
Knative

Abbreviations: ROSA: Red Hat OpenShift on AWS; ARO: Azure Red Hat OpenShift;
EKS: Elastic Kubernetes Services; AKS: Azure Kubernetes Services; GKE: Google
Kubernetes Engine

1.6.1. Spring Cloud Function on AWS

Lambda on AWS
Transforming an application deployed on-premises to leverage an
AWS Lambda environment and be portable requires function code
that abstracts away the hard dependencies of AWS Lambda from the
implementation and the serverless container. This example uses Spring
Cloud Function for the function code framework and Lambda for the
container. By writing once using Spring Cloud Function, you can use the
DevOps pipeline, discussed in subsequent chapters, to deploy to other
serverless environments. Figure 1-11 shows how AWS and its components
help realize the payroll application in the cloud.

20
 Chapter 1 Why Use Spring Cloud Function

Now you need to deploy the payroll system on AWS Lambda. The
deployment sequence is important, as you need to deploy SAP ECC and
Oracle before integrating and then configure API and messaging for the
Spring Cloud Function to integrate with SAP. Spring Cloud Function can be
created and tested with dummy information, but it needs to be deployed
after integration testing with SAP ECC:

1. Deploy SAP ECC on the AWS EC2 instances.

2. Deploy Oracle DB as an RDS instance.

3. Configure the SAP to Oracle integration.

4. Deploy Spring Cloud Function to AWS.

5. Set up the Amazon API Gateway.

6. Set up Amazon SQS for messaging.

Figure 1-11. Spring Cloud Function on AWS

21
Chapter 1 Why Use Spring Cloud Function

1.6.2. Spring Cloud Function on Knative

and EKS on AWS
If you want to implement a truly portable environment in AWS, you can
leverage the AWS EKS, which is a Kubernetes platform that AWS offers.
You can install Knative in EKS and this will give you a truly portable,
serverless container that allows for faster deployment and improved cold
starts. It uses appropriate technologies, such as Spring Cloud Function
on GraalVMs. GraalVMs uses the AOT (Ahead of Time) compilation
technique, which significantly improves execution times. Subsequent
sections address GraalVMs and Spring Cloud Function. See Figure 1-12.
Follow this process to deploy the payroll system on Knative hosted
on an Azure AKS and ensure that the SAP ECC and Oracle DB are up and
integrated. You do this before developing and deploying Spring Cloud
Function on Knative:

1. Deploy SAP ECC on AWS EC2 instances.

2. Deploy Oracle DB as an RDS instance.

3. Configure the SAP to Oracle integration.

4. Set up Knative on an AWS EKS cluster.

5. Deploy Spring Cloud Function on Knative.

6. Set up the Amazon API Gateway.

7. Set up Amazon SQS for messaging.

22
 Chapter 1 Why Use Spring Cloud Function

Figure 1-12. Spring Cloud Function on Knative on AWS

1.6.3. Spring Cloud Function on Cloud

Functions on GCP
GCP Cloud Functions provide a cloud alternative to AWS Lambda
Functions. The GCP offering is newer than Lambda, but with the Anthos
strategy, it is gaining a good amount of the function space. Spring.io works
closely with Google to make the Spring.io components work seamlessly
with the GCP components.
To deploy the payroll system on Cloud Functions on GCP, follow the
process outlined here (see Figure 1-13). Ensure that the SAP ECC and
Oracle DB are up and integrated before developing and deploying Spring
Cloud Function on Cloud Functions:

1. Deploy SAP ECC onto GCE.

2. Deploy Oracle DB on GCE VMs, as there is no AWS

RDS-like service on GCP.

3. Configure the SAP to Oracle integration.

23
Chapter 1 Why Use Spring Cloud Function

4. Set up a GCP Cloud Function project.

5. Deploy Spring Cloud Function onto GCP Cloud

Functions.

6. Deploy Apigee on GCP to host function APIs.

7. Set up the Google Cloud pub/sub messaging

platform.

Figure 1-13. Spring Cloud Function on GCP

1.6.4. Spring Cloud Function on Knative

and GKE on GCP
Knative, as discussed, is a way to make the functions portable. Knative,
incidentally, was created by Google. With GCP, you can set up Knative on
GKE, which is the Kubernetes engine provided by Google.
To deploy the payroll system on Knative hosted on a GCP GKE, follow
the process outlined here (Figure 1-14). Ensure that the SAP ECC and

24
 Chapter 1 Why Use Spring Cloud Function

Oracle DB are up and integrated before developing and deploying Spring

Cloud Function on Knative:

1. Deploy SAP ECC as a Docker image onto the GKE

cluster.

2. Deploy Oracle DB as a Docker image onto the GKE

cluster.

3. Configure the SAP to Oracle integration.

4. Configure a GKE cluster with Knative.

5. Deploy Spring Cloud Function onto Knative.

6. Set up the Apigee API Gateway.

7. Set up RabbitMQ on GKE for messaging.

8. Set up Google cloud pub/sub.

Figure 1-14. Spring Cloud Function on Knative on GCP

25
Chapter 1 Why Use Spring Cloud Function

1.6.5. Spring Cloud Function on Azure Functions

on Azure
Spring Cloud Function deployed on Azure Functions is not portable due
to the explicit use of an Azure Function Invoker class. While Lambda and
Google Cloud Functions require a change to Pom.xml (if you are using
Maven), Azure needs an additional class. This makes it less portable. If you
have a portfolio of one thousand Spring Cloud Functions in AWS that you
need to move to Azure, you have to do a lot of development activity. This is
disruptive.
To deploy the payroll system on Azure Functions, follow the process
outlined here (see Figure 1-15). Ensure that the SAP ECC and Oracle DB
are up and integrated before developing and deploying Spring Cloud
Function on Azure Functions:

1. Deploy SAP ECC on Azure VMs.

2. Deploy Oracle DB on Azure VMs.

3. Configure the SAP to Oracle integration.

4. Configure Azure Functions.

5. Deploy Spring Cloud Function on Azure Functions.

6. Set up the Azure API Gateway on Azure.

7. Set up Azure Queue storage on Azure for messaging.

26
 Chapter 1 Why Use Spring Cloud Function

Figure 1-15. Spring Cloud Function on Azure

1.6.6. Spring Cloud Function on Knative and AKS

on Azure
Knative on Azure AKS is the only option for deploying Spring Cloud
Function on Azure that makes it portable. As in any Kubernetes
implementation, it requires an implementation of Knative to run the
functions. Transforming the payroll application to AKS requires an AKS
cluster.
To deploy the payroll system on Knative hosted on an Azure AKS
environment, follow the process outlined here (Figure 1-16). Ensure that
the SAP ECC and Oracle DB are up and integrated before developing and
deploying Spring Cloud Function on Knative:

1. Deploy SAP ECC on Azure VMs.

2. Deploy Oracle DB on Azure VMs.

3. Configure the SAP to Oracle integration.

4. Configure an AKS cluster with Knative.

27
Chapter 1 Why Use Spring Cloud Function

5. Deploy Spring Cloud Function onto Knative.

6. Set up an Azure API Gateway on AKS.

7. Set up Azure Queue on Azure for messaging.

Figure 1-16. Spring Cloud Function on Knative on Azure

1.6.7. Spring Cloud Function on VMware Tanzu

(TKG, PKS)
VMware Tanzu is an evolution of Pivotal Cloud Foundry (PCF). Those
who are familiar with PCF should be aware of the “cf push” experience.
It was a one-click provisioning approach and was very popular in the
developer community. This is the same experience that Knative provides
through its Knative build feature. To transform the payroll application to
run on VMware Tanzu, you need the Tanzu Kubernetes grid, also known as
TKG. TKG is built using the main branch of Kubernetes code. This can be
deployed on-premises and in the cloud and can facilitate a multi-cloud or
hybrid-cloud strategy. You can start up an instance of TKG on AWS, Azure,
or Google by subscribing to the service in the provider’s marketplace.

28
 Chapter 1 Why Use Spring Cloud Function

In a datacenter, you need a collection of servers or a hyper-converged

infrastructure like VxRail with PRA (Pivotal Ready Architecture). You also
need to upgrade your vSphere to Version 7.
Going back to the payroll application, you need to follow the process
outlined here (Figure 1-17). Ensure that the SAP ECC and Oracle DB have
been up and integrated before developing and deploying Spring Cloud
Function on Knative:

1. Deploy SAP ECC as a Docker image onto TKG.

2. Deploy Oracle DB as a Docker image onto TKG.

3. Configure the SAP to Oracle integration.

4. Configure a TKG cluster with Knative.

5. Deploy Spring Cloud Function onto Knative.

6. Set up a Spring Cloud Gateway on TKG as an API

Gateway.

7. Set up RabbitMQ on TKG for messaging.

29
Chapter 1 Why Use Spring Cloud Function

Figure 1-17. Spring Cloud Function on TKG

Figure 1-18. Four-node VxRail P570F cluster for vSphere with Tanzu
and HAProxy

30
 Chapter 1 Why Use Spring Cloud Function

1.6.8. Spring Cloud Function on Red Hat

OpenShift (OCP)
Red Hat OpenShift can be an on-premises option for deploying Spring
Cloud Function. As in any Kubernetes implementation, it requires an
implementation of Knative to run the functions. OpenShift has its own
serverless implementation, called OpenShift serverless. Transforming the
payroll application to OpenShift requires an OpenShift cluster.
To deploy the payroll system to OpenShift hosted on a VMware
vSphere environment, follow the outlined process. First ensure that the
SAP ECC and Oracle DB are up and integrated before developing and
deploying Spring Cloud Function on Knative:

1. Deploy SAP ECC as a Docker image onto OpenShift

cluster.

2. Deploy an Oracle DB as a Docker image onto the

OpenShift cluster.

3. Configure the SAP to Oracle integration.

4. Configure an OpenShift cluster with Knative.

5. Deploy Spring Cloud Function onto Knative.

6. Set up a Red Hat 3scale API Gateway on OpenShift.

7. Set up RabbitMQ on TKG for messaging.

31
Other documents randomly have
different content
players. The IBM 704 computer has been programmed to inspect the
results of its possible decisions several moves ahead and to select
the best choice. At the end of the game it prints out the winner and
thanks its opponent for the game. Rated as polite, but only an
indifferent player by experts, the computer is much like the checker-
playing dog whose master scoffed at him for getting beaten three
games out of five. Chess may well be an ultimate challenge for any
kind of brain, since the fastest computer in operation today could not
possibly work out all the possible moves in a game during a human
lifetime!
As evidenced in the science-fiction treatment early machines got,
the first computers were monsters at least in size. Pioneering design
efforts on machines with the capacity of the brain led to plans for
something roughly the size of the Pentagon, equipped with its own
Niagara for power and cooling, and a price tag the world couldn’t
afford. As often seems to happen when a need arises, though, new
developments have come along to offset the initial obstacles of size
and cost.
One such development was the transistor and other
semiconductor devices. Tiny and rugged, these components require
little power. With the old vacuum-tubes replaced, computers shrank
immediately and dramatically. On the heels of this micro-
miniaturization have come new and even smaller devices called
“ferrite cores” and “cryotrons” using magnetism and supercold
temperatures instead of conventional electronic techniques.
As a result, an amazing number of parts can be packed into a tiny
volume. So-called “molecular electronics” now seems to be a
possibility, and designers of computers have a gleam in their eyes as
they consider progress being made toward matching the “packaging
density” of the brain. This human computer has an estimated 100
billion parts per cubic foot!
We have talked of reading and translating. Some new computers
can also accept voice commands and speak themselves. Others
furnish information in typed or printed form, punched cards, or a
display on a tube or screen.
 Like us, the computer can be frustrated by a task beyond its
capabilities. A wrong command can set its parts clicking rapidly but
in futile circles. Early computers, for example, could be panicked by
the order to divide a number by zero. The solution to that problem of
course is infinity, and the poor machine had a hard time trying to
make such an answer good.

Aeronutronic Division, Ford Motor Co.

This printed-circuit card contains more than 300 BIAX memory elements. Multiples
of such cards mounted in computers store large amounts of information.

There are other, quainter stories like that of the pioneer General
Electric computer that simply could not function in the dark. All day
long it hummed efficiently, but problems left with it overnight came
out horribly botched for no reason that engineers could discover. At
last it was found that a light had to be left burning with the scary
machine! Neon bulbs in the computer were enough affected by light
and darkness that the delicate electronic balance of the machine had
been upset.
Among the computer’s unusual talents is the ability to compose
music. Such music has been published and is of a quality to give rise
to thoughtful speculation that perhaps great composers are simply
good selectors of music. In other words, all the combinations of
notes and meter exist: the composer just picks the right ones. No
less an authority than Aaron Copland suggests that “we’ll get our
new music by feeding information into an electronic computer.” Not
content with merely writing music, some computers can even play a
tune. At Christmas time, carols are rendered by computers specially
programmed for the task. The result is not unlike a melody played on
a pipe organ.
In an interesting switch of this musical ability on the part of the
machine, Russian engineers check the reliability of their computers
by having them memorize Mozart and Grieg. Each part of the
complex machines is assigned a definite musical value, and when
the composition is “played back” by the computer, the engineer can
spot any defects existing in its circuitry. Such computer maintenance
would seem to be an ideal field for the music lover.
In a playful mood, computers match pennies with visitors, explain
their inner workings as they whiz through complex mathematics, and
are even capable of what is called heuristic reasoning. This amounts
to playing hunches to reach short-cut solutions to otherwise
unsolvable problems. A Rand Corporation computer named
JOHNNIAC demonstrated this recently. It was given some basic
axioms and asked to prove some theorems. JOHNNIAC came up
with the answers, and in one case produced a proof that was simpler
than that given in the text. As one scientist puts it, “If computers don’t
really think, they at least put on a pretty creditable imitation of the
real thing.”
 Computers are here to stay; this has been established beyond
doubt. The only question remaining is how fast the predictions made
by dreamers and science-fiction writers—and now by sober
scientists—will come to be a reality. When we consider that in the
few years since the 1953 crop of computers, their capacity and
speed has been increased more than fiftyfold, and is expected to
jump another thousandfold in two years, these dreams begin to
sound more and more plausible.
One quite probable use for computers is medical diagnosis and
prescription of treatment. Electronic equipment can already monitor
an ailing patient, and send an alarm when help is needed. We may
one day see computers with a built-in bedside manner aiding the
family doctor.
The accomplished inroads of computing machines in business are
as nothing to what will eventually take place. Already computer
“game-playing” has extended to business management, and serious
executives participate to improve their administrative ability. We
speak of decision-making machines; business decisions are logical
applications for this ability. Computers have been given the job of
evaluating personnel and assigning salaries on a strictly logical
basis. Perhaps this is why in surveys questioning increased use of
the machines, each executive level in general tends to rate the
machine’s ability just below its own.
Other games played by the computer are war games, and
computers like SAGE are well known. This system not only monitors
all air activity but also makes decisions, assigns targets, and then
even flies the interceptor planes and guided missiles on their
missions. Again in the sky, the increase of commercial air traffic has
perhaps reached the limit of human ability to control it. Computers
are beginning to take over here too, planning flights and literally
flying the planes.
Surface transport can also be computer-controlled. Railroads are
beginning to use the computer techniques, and automatic highways
are inevitable. Ships also benefit, and special systems coupled to
radar can predict courses and take corrective action when
necessary.
Men seem to have temporarily given up trying to control the
weather, but using computers, meteorologists can take the huge
mass of data from all over the world and make predictions rapidly
enough to be of use.
We have talked of the computer’s giant strides in banking. Its wide
use in stores is not far off. An English computer firm has designed an
automatic supermarket that assembles ordered items, prices them,
and delivers them to the check stand. At the same time it keeps a
running inventory, price record, and profit and loss statement,
besides billing the customer with periodic statements. The
storekeeper will have only to wash the windows and pay his electric
power bill.
Even trading stamps may be superseded by computer techniques
that keep track of customer purchases and credit him with premiums
as he earns them. Credit cards have helped pioneer computer use in
billing; it is not farfetched to foresee the day when we are issued a
lifetime, all-inclusive credit card—perhaps with our birth certificate!—
a card with our thumbprint on it, that will buy our food, pay our rent
and utilities and other bills. A central computer system will balance
our expenses against deposits and from time to time let us know
how we stand financially.
As with many other important inventions, the computer and its
technology were spurred by war and are aided now by continuing
threats of war. It is therefore pleasant to think on the possibilities of a
computer system “programmed” for peace: a gigantic, worldwide
system whose input includes all recorded history of all nations, all
economic and cultural data, all weather information and other
scientific knowledge. The output of such a machine hopefully would
be a “best plan” for all of us. Such a computer would have no ax to
grind and no selfish interests unless they were fed into it.
Given all the facts, it would punch out for us a set of instructions
that would guarantee us the best life possible. This has long been a
dream of science writers. H. G. Wells was one of these, suggesting a
world clearinghouse of information in his book World Brain written in
the thirties. In this country, scientist Vannevar Bush suggested a
similar computer called “Memex” which could store huge amounts of
data and answer questions put to it.
The huge amounts of information—books, articles, speeches, and
records of all sorts—are beginning to make it absolutely necessary
for an efficient information retrieval system. Many cases have been
noted in which much time and effort are spent on a project which has
already been completed but then has become lost in the welter of
literature crammed into libraries. The computer is a logical device for
such work; in a recent test such a machine scored 86 per cent in its
efforts to locate specific data on file. Trained workers rated only 38
per cent in the same test!

The Boeing Co.

Engineers using computers to solve complex problems in aircraft design.

 The science of communication is advancing along with that of
computers, and can help make the dream of a worldwide “brain”
come true. Computers in distant cities are now linked by telephone
lines or radio, and high-speed techniques permit the transmission of
many thousands of words per second across these “data links.” An
interesting sidelight is the fact that an ailing computer can be hooked
by telephone line with a repair center many miles away and its
ailments diagnosed by remote control. Communications satellites
that are soon to be dotting the sky like tiny moons may well play a
big part in computing systems of the future. Global weather
prediction and worldwide coordination of trade immediately come to
mind.
While we envision such far-reaching applications, let’s not lose
sight of the possibilities for computer use closer to home—right in
our homes, as a matter of fact. Just as early inventors of mechanical
power devices did not foresee the day when electric drills and saws
for hobbyist would be commonplace and the gasoline engine would
do such everyday chores as cutting the grass in our yards, the
makers of computers today cannot predict how far the computer will
go in this direction. Perhaps we may one day buy a “Little Dandy
Electro-Brain” and plug it into the wall socket for solving many of the
everyday problems we now often guess wrong on.
 Royal McBee Corp.

Students at Staples High School, Westport, Connecticut, attend a summer session

to learn the techniques of programming and operating an electronic computer.
 The Saturday Evening Post

“Herbert’s been replaced by an electronic brain—one of the simpler types.”

Some years ago a group of experts predicted that by 1967 the

world champion chess player would be an electronic computer. No
one has yet claimed that we would have a president of metal and
wire, but some interesting signposts are being put up. Computers
are now used widely to predict the result of elections. Computers
count the votes, and some have suggested that computers could
make it possible for us to vote at home. The government is
investigating the effectiveness of a decision-making computer as a
stand-by aid for the President in this complex age we are moving
into. No man has the ability to weigh every factor and to make
decisions affecting the world. Perhaps a computer can serve in an
advisory capacity to a president or to a World Council; perhaps—
It is comforting to remember that men will always tell the computer
what it is supposed to do. No computer will ever run the world any
more than the cotton gin or the steam engine or television runs the
world. And in an emergency, we can always pull out the wallplug,
can’t we?
“History is but the unrolled scroll of prophecy.”

—James A. Garfield
2: The Computer’s Past

Although it seemed to burst upon us suddenly, the jet airplane

can trace its beginnings back through the fabric wings of the Wrights
to the wax wings of Icarus and Daedalus, and the steam aerophile of
Hero in ancient Greece. The same thing is true of the computer, the
“thinking machine” we are just now becoming uncomfortably aware
of. No brash upstart, it has a long and honorable history.
Naturalists tell us that man is not the only animal that counts.
Birds, particularly, also have an idea of numbers. Birds, incidentally,
use tools too. We seem to have done more with the discoveries than
our feathered friends; at least no one has yet observed a robin with a
slide rule or a snowy egret punching the controls of an electronic
digital computer. However, the very notion of mere birds being tool
and number users does give us an idea of the antiquity and lengthy
heritage of the computer.
The computer was inevitable when man first began to make his
own problems. When he lived as an animal, life was far simpler, and
all he had to worry about was finding game and plants to eat, and
keeping from being eaten or otherwise killed himself. But when he
began to dabble in agriculture and the raising of flocks, when he
began to think consciously and to reflect about things, man needed
help.
First came the hand tools that made him more powerful, the
spears and bows and arrows and clubs that killed game and
enemies. Then came the tools to aid his waking brain. Some 25,000
years ago, man began to count. This was no mean achievement, the
dim, foggy dawning of the concept of number, perhaps in the caves
in Europe where the walls have been found marked with realistic
drawings of bison. Some budding mathematical genius in a skin
garment only slightly shaggier than his mop of hair stared blinking at
the drawings of two animals and then dropped his gaze to his two
hands. A crude, tentative connection jelled in his inchoate gray
matter and he shook his head as if it hurt. It was enough to hurt, this
discovery of “number,” and perhaps this particular pioneer never
again put two and two together. But others did; if not that year, the
next.
Armed with his grasp of numbers, man didn’t need to draw two
mastodons, or sheep, or whatever. Two pebbles would do, or two
leaves or two sticks. He could count his children on his fingers—we
retain the expression “a handful” to this day, though often our
children are another sort of handful. Of course, the caveman did not
of a sudden do sums and multiplications. When he began to write,
perhaps 5,000 years later, he had formed the concept of “one,” “two,”
“several,” and “many.”
Besides counting his flock and his children, and the number of the
enemy, man had need for counting in another way. There were the
seasons of the year, and a farmer or breeder had to have a way of
reckoning the approach of new life. His calendar may well have been
the first mathematical device sophisticated enough to be called a
computer.
It was natural that numbers be associated with sex. The calendar
was related to the seasons and the bearing of young. The number
three, for example, took on mystic and potent connotation,
representing as it did man’s genitals. Indeed, numbers themselves
came quaintly to have sex. One, three, and the other odd numbers
were male; the symmetrical, even numbers logically were female.
The notion that man used the decimal system because of his ten
fingers and toes is general, but it was some time before this
refinement took place. Some early peoples clung to a simpler system
with a base of only two; and interestingly a tribe of Australian
aborigines counts today thus: enea (1), petchaval (2), enea
petchaval (3), petchaval petchaval (4). Before we look down our
noses at this naïve system, let us consider that high-speed electronic
computers use only two values, 1 and 0.
But slowly symbols evolved for more and more numbers, numbers
that at first were fingers, and then perhaps knots tied in a strip of
hide. This crude counting aid persists today, and cowboys
sometimes keep rough tallies of a herd by knotting a string for every
five that pass. Somehow numbers took on other meanings, like
those that figure in courtship in certain Nigerian tribes. In their
language, the number six also means “I love you.” If the African belle
is of a mind when her boyfriend tenderly murmurs the magic number,
she replies in like tone, “Eight!”, which means “I feel the same way!”
From the dawn of history there have apparently been two classes
of us human beings, the “haves” and the “have nots.” Nowadays we
get bills or statements from our creditors; in early days, when a slate
or clay tablet was the document, a forerunner of the carbon copy or
duplicate paper developed. Tallies were marked for the amount of
the debt, the clay tablet was broken across the marks, and creditor
and debtor each took half. No chance for cheating, since a broken
half would fit only the proper mate!
Numbers at first applied only to discrete, or distinctly separate,
things. The scratches on a calendar, the tallies signifying the count of
a flock; these were more easily reckoned. The idea of another kind
of number inspired the first clocks. Here was a monumental
breakthrough in mathematics. Nature provided the sunrise that
clearly marked the beginning of each day; man himself thought to
break the day into “hours,” or parts of the whole. Such a division led
eventually to measurement of size and weight. Now early man knew
not only how many goats he had, but how many “hands” high they
were, and how many “stones” they weighed. This further division
ordained another kind of mechanical computer man must someday
contrive—the analog.
The first counting machines used were pebbles or sea shells. For
the Stone Age businessman to carry around a handful of rocks for all
his transactions was at times awkward, and big deals may well have
gone unconsummated for want of a stone. Then some genius hit on
the idea of stringing shells on a bit of reed or hide; or more probably
the necklace came first as adornment and the utilitarian spotted it
after this style note had been added. At any rate, the portable adding
machine became available and our early day accountant grew adroit
at sliding the beads back and forth on the string. From here it was
only a small step, taken perhaps as early as 3000 B.C., to the rigid
counter known as the abacus.
The word “counter” is one we use in everyday conversation. We
buy stock over the counter; some deals are under the counter. We all
know what the counter itself is—that wide board that holds the cash
register and separates us from the shopkeeper. At one time the cash
register was the counter; actually the counting board had rods of
beads like the abacus, or at least grooves in which beads could be
moved. The totting up of a transaction was done on the “counter”; it
is still there although we have forgotten whence came its name.
The most successful computer used for the next 5,000 years, the
portable counter, or the abacus, is a masterpiece of simplicity and
effectiveness. Though only a frame with several rows of beads, it is
sophisticated enough that as late as 1947 Kiyoshi Matsuzake of the
Japanese Ministry of Communications, armed with the Japanese
version—a soroban, bested Private Tom Wood of the U. S. Army of
Occupation punching the keys of an up-to-the-minute electric
calculating machine in four of five problem categories! Only recently
have Japanese banks gone over to modern calculators, and
shopkeepers there and in other lands still conduct business by this
rule of thumb and forefinger.
 The abacus, ancient mechanical computer, is still in use in many parts of the
world. Here is the Japanese version, the soroban, with problem being set up.

The name abacus comes to us by way of the Greek abax,

meaning “dust.” Scholars infer that early sums were done schoolboy
fashion in Greece with a stylus on a dusty slate, and that the word
was carried over to the mechanical counter. The design has changed
but little over the years and all abacuses bear a resemblance. The
major difference is the number of beads on each row, determined by
the mathematical base used in the particular country. Some in India,
for example, were set up to handle pounds and shillings for use in
shops. Others have a base of twelve. The majority, however, use the
decimal system. Each row has seven beads, with a runner
separating one or two beads from the others. Some systems use two
beads on the narrow side, some only one; this is a mathematical
consideration with political implications, incidentally: The Japanese
soroban has the single-bead design; Korea’s son pan uses two.
When Japan took over Korea the two-bead models were tabu, and
went out of use until the Koreans were later able to win their
independence again.
About the only thing added to the ancient abacus in recent years is
a movable arrow for marking the decimal point. W. D. Loy patented
such a gadget in the United States. Today the abacus remains a
useful device, not only for business, but also for the teaching of
mathematics to youngsters, who can literally “grasp their numbers.”
For that reason it ought also to be helpful to the blind, and as a
therapeutic aid for manual dexterity. Apparently caught up in the
trend toward smaller computers, the abacus has been miniaturized
to the extent that it can be worn as earrings or on a key chain.
Even with mechanical counters, early mathematicians needed
written numbers. The caveman’s straight-line scratches gave way to
hieroglyphics, to the Sumerian cuneiform “wedges,” to Roman
numerals, and finally to Hindu and Arabic. Until the numbers, 1, 2, 3,
4, 5, 6, 7, 8, 9, and that most wonderful of all, 0 or zero,
computations of any but the simplest type were apt to be laborious
and time-consuming. Even though the Romans and Greeks had
evolved a decimal system, their numbering was complex. To count to
999 in Greek required not ten numbers but twenty-seven. The
Roman number for 888 was DCCCLXXXVIII. Multiplying CCXVII
times XXIX yielded an answer of MMMMMMCCXCIII, to be sure, but
not without some difficulty. It required an abacus to do any kind of
multiplication or division.
 Indeed, it was perhaps from the abacus that the clue to Arabic
simplicity came. The Babylonians, antedating the Greeks, had
nevertheless gone them one better in arithmetic by using a “place”
system. In other words, the position of a number denoted its value.
The Babylonians simply left an empty space between cuneiform
number symbols to show an empty space in this positional system.
Sometime prior to 300 B.C. a clever mathematician tired of losing
track and punched a dot in his clay tablet to fill the empty space and
avoid possible error.
The abacus shows these empty spaces on its rows of beads, too,
and finally the Hindus combined their nine numerals with a “dot with
a hole in it” and gave the mathematical world the zero. In Hindu it
was sifr, corrupted to zephirium in Latin, and gives us today both
cipher and zero. This enigma of nothingness would one day be used
by Leibnitz to prove that God made the world; it would later become
half the input of the electronic computer! Meantime, it was developed
independently in various other parts of the world; the ancient Mayans
being one example.
Impressed as we may be by an electronic computer, it may take
some charity to recognize its forebears in the scratchings on a rock.
To call the calendar a computer, we must in honesty add a qualifying
term like “passive.” The same applies to the abacus despite its
movable counters. But time, which produced the simple calendar,
also furnished the incentive for the first “active” computers too. The
hourglass is a primitive example, as is the sundial. Both had an
input, a power source, and a readout. The clock interestingly ended
up with not a decimal scheme, but one with a base of twelve. Early
astronomers began conventionally bunching days into groups of ten,
and located different stars on the horizon to mark the passage of the
ten days. It was but a step from here to use these “decans,” as they
were called, to further divide each night itself into segments. It turned
out that 12 decans did the trick, and since symmetry was a virtue the
daylight was similarly divided by twelve, giving us a day of 24 hours
rather than 10 or 20.
From the simple hourglass and the more complex water clocks,
the Greeks progressed to some truly remarkable celestial motion
computers. One of these, built almost a hundred years before the
birth of Christ, was recently found on the sea bottom off the Greek
island of Antikythera. It had been aboard a ship which sank, and its
discovery came as a surprise to scholars since history recorded no
such complex devices for that era. The salvaged Greek computer
was designed for astronomical work, showing locations of stars,
predicting eclipses, and describing various cycles of heavenly
bodies. Composed of dozens of gears, shafts, slip rings, and
accurately inscribed plates, it was a computer in the best sense of
the word and was not exceeded technically for many centuries.
The Greek engineer Vitruvius made an interesting observation
when he said, “All machinery is generated by Nature and the
revolution of the universe guides and controls. Our fathers took
precedents from Nature—developed the comforts of life by their
inventions. They rendered some things more convenient by
machines and their revolutions.” Hindsight and language being what
they are, today we can make a nice play on the word “revolution” as
applied to the machine. The Antikythera computer was a prime
example of what Vitruvius was talking about. Astronomy was such a
complicated business that it was far simpler to make a model of the
many motions rather than diagram them or try to retain them in his
mind.
There were, of course, some die-hard classicists who decried the
use of machines to do the work of pure reasoning. Archytas, who
probably invented the screw—or at least discovered its mechanical
principle—attempted to apply such mechanical devices to the solving
of geometrical problems. For this he was taken to task by purist
Plato who sought to preserve the distinct division between “mind”
and “machine.”
Yet the syllogistic philosophers themselves, with their major
premise, minor premise, and conclusion, were unwittingly setting the
stage for a different kind of computer—the logic machine. Plato
would be horrified today to see crude decks of cards, or simple
electromechanical contrivances, solving problems of “reason” far
faster than he could; in fact, as fast as the conditions could be set
into them!
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebooknice.com