This document discusses building serverless applications with Go and the Serverless Application Model (SAM). It begins with confidentiality and disclaimer sections. It then provides an introduction to Project Flogo, an open source serverless framework for building event-driven applications. Project Flogo uses Go and allows developers to define app logic as flows that connect triggers and actions. The document discusses how Flogo provides both a visual UI and Go API for application development and describes ways to get started using Flogo's CLI, Docker images, or Go library.
2. Confidentiality
The following information is confidential information of TIBCO
Software Inc. Use, duplication, transmission, or republication for
any purpose without the prior written consent of TIBCO is
expressly prohibited.
3. Disclaimer
This document (including, without limitation, any product roadmap or
statement of direction data) illustrates the planned testing, release and
availability dates for TIBCO products and services. This document is provided
for informational purposes only and its contents are subject to change without
notice. TIBCO makes no warranties, express or implied, in or relating to this
document or any information in it, including, without limitation, that this
document, or any information in it, is error-free or meets any conditions of
merchantability or fitness for a particular purpose. This document may not be
reproduced or transmitted in any form or by any means without our prior
written permission.
The material provided is for informational purposes only, and should not be
relied on in making a purchasing decision. The information is not a
commitment, promise or legal obligation to deliver any material, code, or
functionality. The development, release, and timing of any features or
functionality described for our products remains at our sole discretion.
During the course of this presentation TIBCO or its representatives may make
forward-looking statements regarding future events, TIBCO’s future results or
our future financial performance. These statements are based on
management’s current expectations. Although we believe that the expectations
reflected in the forward-looking statements contained in this presentation are
reasonable, these expectations or any of the forward-looking statements could
prove to be incorrect and actual results or financial performance could differ
materially from those stated herein. TIBCO does not undertake to update any
forward-looking statement that may be made from time to time or on its
behalf.
4. •Developer Advocate at
TIBCO
•Passionate about Open
Source, Cloud, Containers
and Serverless
•I love cheesecake, dad
jokes, and APIs
Leon Stigter, Developer Advocate
( @LeonStigter)
Who Am I?
7. …Transforming data
into action…
To spot and seize
opportunities from the ever
increasing volumes of data
and devices
…Operating with
more speed and
agility…
To meet stakeholder
demands for delivering
rapid innovation and
differentiation
…Empowering
more users…
To become self-sufficient at
helping the business with
digital transformation
efforts
Why Do We Build Apps?
9. ESB
…From building and
connecting monolithic
applications to each other…
App App App
…To also becoming the infrastructure on which modern
applications are built, with API and event-driven
microservices patterns, to support digital transformation
needs
Technically the strategy must “integrate integration” and
blur the lines between development and integration
-Randy Heffner, Forrester Research
Service Service
Service
API
EVENT
API
EVENT
API
API
“App”
Function
Function
The Way We Build Apps Is Changing
11. “...among those having implemented REST APIs, only 25% say that all or nearly all of them
are designed as entirely CRUD APIs, which shows that many organizations feel the need to go
against the religion.”
“...among development managers with internal APIs, 23% said they have important use cases,
where one call to an API must update multiple applications.”
Microservices enable use cases beyond simple point-to-point CRUD
“Among development managers who said that changing their business model was likely
to be a critical or high business priority, 62% already have
microservices or plan to have them by early 2018.”
Source: Forrester Research
Microservices and External APIs Underpin Digital Business (Oct 17, 2017)
12. “Dynamic Cloud” Deployment Growth
• More enterprise
strategic workloads
are now run in the
cloud than on-premise
• The highest workload
% is using “Dynamic
Cloud”; FaaS and
Serverless technology
Source: The New Stack, 2017 Survey
14. So…
Let’s recap for a second…
• If you’re building apps…
• And everyone is building apps with you…
• And we’re breaking down monoliths…
• And we’re moving to the cloud…
• And change is really, really hard…
15. In That Case There Is Only One
Solution…
NEVER MANAGE SERVERS
16. Let’s Talk Serverless…
Scales with usage
Never pay for idle
No servers to provision
Or manage
Availability and
Fault-tolerance built in
17. Reuse some standard building blocks
Amazon API
Gateway
Amazon SQS
Amazon
DynamoDB
Amazon
Kinesis
Amazon S3
Amazon SNS
Let’s Talk Serverless…
18. Project Flogo
Open Source Stack for Event-Driven Apps
Build smarter with Edge
Machine Learning
10-50x lighter than
Java, .NET or Node.js
Visually model & test
flows as functions
Event-driven design
with native support for
AWS Lambda
100% Open Source with
zero lock-in
What Is Project Flogo?
19. If your background is in or you
prefer to develop your apps
using zero-coding
environments.
Flogo Web UI is available via
Docker Hub or Flogo.io.
It contains everything required
to get started in seconds!
Who Is Project Flogo Meant For?
20. Getting started with the CLI
couldn't be any easier:
go get -u
github.com/TIBCOSoftware/f
logo-cli/...
Or
go get -u
github.com/TIBCOSoftware/f
logo-lib/...
Who Is Project Flogo Meant For?
21. Java, NodeJS are great, but too large for resource constrained environments
Why Golang for Project Flogo:
➢ Complies natively and runs natively.
➢ Only the required dependencies are built into the application.
➢ Static linking enables zero OS dependencies.
App
Framework (OSGi)
VM (JVM)
Operating System
Hardware
App
Framework (Node.js)
VM (V8)
Operating System
Hardware
App
Operating System
Hardware
But Why Go?
22. The Basics of Project
Flogo
➢ At its core, flogo is an event-driven
framework
➢ The intent is for the event sources
(Triggers) and Actions to be pluggable
contributions
➢ The Web-UI uses the FlowAction
23. The Basics of Project
Flogo
Image from https://www.youtube.com/watch?v=r7lMGPM3u9E
25. ➢ Basically an “action” to perform on
receiving the event
➢ Can be simple go code which
implements the Action interface
➢ Contributed Actions, such as the
FlowAction used by our UI
Event
Stream
Kafka
Triggers: Kafka,
REST, MQTT,
etc…
Flow
Golang Package
Actions
Actions
28. Low friction web-native UX
➢ Express app logic using rich
flows, not just data or
request pipelines
➢ Inline data transformations
➢ Built-in web-based debugger
➢ Build for target platform
directly from UI
➢ Available on Docker Hub or
Flogo.io
How To Build an App? We Have a UI
29. ➢ Wraps all common commands for building
Flogo applications
➢ Wrapper around go `dep` and `go` cli
➢ Parses DSL for
➢ dependencies
➢ Importing req packages
➢ main.go
➢ embedding app
How To Build an App? We Have a CLI
32. No UI
Shouldn’t require a UI or JSON
API driven
Must provide a simple API for
app composition and execution
Reuse concepts
Must allow users to use existing
triggers, actions and activities
Mix with Go
Should be easy to invoke custom
code in response to a event from
a trigger
Developer Experience: Flogo-as-a-Lib
33. func main() {
app := flogo.NewApp()
trg := app.NewTrigger(&rest.RestTrigger{}, map[string]interface{}{"port": 8080})
trg.NewFuncHandler(map[string]interface{}{"method": "GET", "path": "/blah"},
RunActivities)
e, err := flogo.NewEngine(app)
if err != nil {
logger.Error(err)
return
}
engine.RunEngine(e)
}
func RunActivities(ctx context.Context, inputs map[string]*data.Attribute)
(map[string]*data.Attribute, error) {
in := map[string]interface{}{"message": "test"}
_, err := flogo.EvalActivity(&log.LogActivity{}, in)
if err != nil {
return nil, err
}
return nil, nil
}
Use triggers & function
handlers
Call activities
So We Also Have a Go API!
36. github.com/TIBCOSoftware/flogo
$ docker run -it -p 3303:3303 flogo/flogo-docker eula-accept
Building via the CLI
$ go get github.com/TIBCOSoftware/flogo-cli
Getting Started with Project Flogo