1
● Continuous Integration
● Pipelines
● Continuous Testing
● Microservices
● Continuous Delivery
● CHAOS
● Integration Issues
● Misunderstandings
● Waiting
● Blockers
My Teams Should Be
Moving Faster!
You are adopting “DevOps” and “Microservices” because of the promise of delivering
value faster to your users/customers. But you are not seeing the gains you want to
see. You’ve got CI/CD/Pipelines/Tests/Microservices/etc… But you are still getting
bogged down with teams being dependent on the progress of each other. Service A
isn’t done, so service B cannot work on integration. The UI requires access to ALL of
the services, so it has to wait until the end to be integrated, and integration takes
WEEKS because of back-and-forth issues between the frontend and backend and
between different dependent services. This is NOT how this is supposed to work!
Many of us are familiar with writing code which other people interface with. In C & C+
+ we provide header files to tell other people what our code can do for them. In Java
it might be an Interface definition. This works great for compile-time guarantees, but
what do you do when you are writing services which work over the network or over
the web?
If you have ever written an API or service which is consumed by others, even inside
of your own team, this should be obvious. Every time you make a change to your
service, those external and internal users are going to be annoyed because you just
broke a BUNCH of their code. Take that annoyance and then consider what happens
where there are multiple (perhaps multitudes of) services and worse yet when those
APIs are consumed in the public by your customers. Add into that all of the
complexities of operating a distributed system and you have a recipe for disaster.

2
Source:
https://twitter.com/jezhumble/status/1021897540445196288
Service Architectures Are HARD
“Reminder: If you're building microservices,
you're building a distributed system.”
- Jez Humble
Lots of people have jumped on the Microservices bandwagon in recent years without
TRULY understanding what that means. They have heard that their developer teams
can achieve greater productivity, that their applications can achieve greater
scalability, that their organizations can achieve greater agility, etc… What they fail to
consider, in order to capitalize on those promises, is that they MUST fundamentally
change how their teams/customers/consumers/partners work together. JUST
implementing microservices is NOT going to achieve those goals because you are
now designing a distributed system, and those components all have to work in a
coordinated fashion. If you do not have a way for those disparate groups to
coordinate with one another asynchronously, then you still have a major bottleneck.
Your back-end devs are waiting on Database schemas and provisioning, your front-
end devs are awaiting an API to code against, your customers and partners are
awaiting documentation of those APIs in order to integrate with your services, etc….

Why You Should Be Doing Contract-
First API Development
Deven Phillips
Architect, Cloud-Native Runtimes Practice
@infosec812
3

4
Why Contract-First?
Source:
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md
● Unambiguous Requirements
● Strong Guarantees
● Enhanced Collaboration
● Parallel Workstreams
● Code Generation
Now that I set the stage for the bad things about cloud-native and microservices
development, let’s talk about how we can make it better…
When you have an API contract, you have enabled:
- Unambiguous requirements - An API contract leaves no doubt or question
about how the API MUST function, and the contract can be used to validate
any implementation
- The Contract provides strong guarantees in the same way that Header files in
C and interfaces in Java provide guarantees. If you comply with the contact, it
will work.
- Enhanced collaboration - The contract provides a place for developers,
consumers, customers, and partners to collaborate on improve the API before
any code is even written
- Parallel Worksteams - And because of these things, we can allow developers
and teams to work independently and in parallel without concern about
compatibility of integration issues
- Code generation - And last, but not least, is the ability to generate the majority
of the boilerplate code - And trust me, this works and is very effective.
Regardless of if you find the code generation and tooling useful, having a simple
format for sharing the contracts for your services amongst all of the users of that
service is of significant value. Let’s learn a little about how simple and expressive it is
to write OpenAPI specifications.

What WAS My Workflow?
5 Source:
https://swagger.io/docs/specification/about/
https://www.apicur.io/
https://openapi-generator.tech/
Build An API Specification
Using a tool like OpenAPI, write an API
specification FIRST
Publish The API Specification
Using a tool like Swagger or Apicur.io, publish
the API specification where others have access
and can collaborate
Generate Code Contracts
Using a tool like OpenAPI Generator, create the
API stubs for both client and server applications.
You can also generate “mock” services and
client SDK libraries!
When I first started to learn about and then teach about API development in this
manner, I had a workflow like what is pictured above. We would build the contract,
publish it and collaborate with consumers of the contract to find out what was right,
what was wrong, what needed improvement, and then we would go an implement the
API. This was OK, and quite effective. We could get the backend implemented so
much faster and avoid lots of wasted effort because we worked out the issues before
we ever invested time in writing implementation code. This was before I had really
been using this extensively across multiple
teams/products/customers/languages/frameworks. This lead to some modifications to
how I, and my team, started using API contracts.

What is my NEW Workflow?
6 Source:
https://swagger.io/docs/specification/about/
https://www.apicur.io/
Using a tool like OpenAPI,
write an API specification
FIRST
Using a tool like Swagger or
Apicur.io, publish the API
specification where others have
access and can collaborate
Using a tool like OpenAPI
Generator, create the stubs for
the server implementation in your
language of choice.
Design
If you will be creating a UI, create prototypes and rough
implementations. Do usability research with target
users of the UI or API
But I have recently started to see an emergent behavior among my teams,
customers, and colleagues who are adopting Contract-First…
We let the users drive the design of the API… Through user research and design
thinking we determine how the application (and by extension the API) should work.
Especially when developing UIs with APIs… If we prototype and implement the UI
while completely disregarding the backend implementation… For example, we
implement a Vue or React single-page app and work out all of the data that we need
to make a workable user experience. We do usability testing with that UI and get
feedback. We unchain those UI developers to implement the best user experience
possible… We actually have NPM scripts and automation set up in our projects to
allow for live coding the UI against a mock API implementation. If the UI developers
need to change something in the API, they modify the contract and the automation
regenerates the API client and the mock API server reloads and adjusts almost
instantly. This leads to outstanding user experiences because we are focused on
meeting the needs of the users/consumers rather than trying to get the right data
from a backend we didn’t have enough say in defining.

When Designing For A UI
7
Source:
https://github.com/JustinFeng/fakeit
https://vuejs.org/
https://reactjs.org
https://appdev.consulting.redhat.com/tracks/contract-first/contract-first-for-ui-development.html
Dev Server
OpenAPI
Spec
HTTP/REST
When we’re developing an API-driven Vue or React app, we add an OpenAPI YAML
contract to the project. We launch “FakeIt” to provide a mock REST server we can
code against… When we need an API call to get data for the UI, we write it into the
OpenAPI Spec and our package.json is configured to automatically rebuild our API
client code using OpenAPI Generator. FakeIt also watches the OpenAPI YAML file
and updates when the file changes. This means that we can tweak the API in nearly
real-time and only write the implementation once we are certain that the API will suit
the needs of the people who will use it.
I recommend you watch the video our team has published on YouTube showing how
this works with an example Vue application.

Developing The API Server Implementation
8 Source:
https://appdev.consulting.redhat.com/tracks/contract-first/
https://schemathesis.readthedocs.io/en/stable/
API Contract OpenAPI Generator
SCHEMATHESIS
Test &
Validate
We take the API contract, we generate the server stubs in our preferred language or
framework, implement the business logic/persistence. All the while we are using a
tool like Schemathesis to automatically test our implementation by using the API
contract to create validations. No code needed and schemathesis will generate
HUNDREDS of tests for each operation in our API Spec. Without needing to write
any tests we can know at development time if our implementation satisfies our API
contract. THAT is shifting left and shortening feedback cycles. That’s not to say that
we don’t need to write tests, but we’re able to write fewer tests and develop faster
with a clear and visible finish-line.

But the generated code isn’t right for my . . .
9
Source:
https://appdev.consulting.redhat.com/tracks/contract-first/
https://mustache.github.io/
https://github.com/redhat-appdev-practice/
CUSTOMIZE IT!
...team!
...organization!
...database!
...library!
...security!
…compliance!
In our experience, the code which is generated should be treated like a “black box”....
You should never directly modify it. We go so far as to say that generated code
should not even be committed to version control. You should instead seek to extend
the generated code through composition or inheritance… If that’s insufficient, then
you can customize the code being generated. We have done this ourselves with
OpenAPI Generator and it’s Mustache Templates. We have added things like ORM
support, distributed tracing support, metrics and monitoring support, health checks,
and more. This is an opportunity. Those of you who are or seek to become architects
can build out best-practices into your customized OpenAPI Generator Templates and
everyone in the company can benefit the next time they update their build! It
accelerates innovation for every team using that language/framework! We have
several examples of customized OpenAPI Generator templates on our GitHub site
linked in this slide.

10
● Design First
● Get Feedback From Users
● Generate Server Code
● Generated Code Is Disposable
● Use Automated Testing Tools
● Publish Client Libraries
Lessons Learned
Design First! Make sure that the API you are preparing to create is the API that your
users will love to use. You can achieve that by performing user research. Look into
The “Sprint” book and learn how a Design Sprint is done and how the associated
user research is done… Even better, hire a designer!
Once you have confirmed your API design, GENERATE most of the server code
using a tool like OpenAPI Generator. This will have multiple positive effects:
1. It pretty much guarantees that your server complies with the API Spec
2. You avoid writing a lot of boilerplate code
3. You make it easier to do Test Driven Development
4. When your API Spec changes, you get hints from your IDE/Build Tools about
what needs to be changed
Treat the generated code the way that all generated code should be treated, ignore
it… Specifically, gitignore it. Let your build process regenerate the code on every
build. This ensures that your API is always up-to-date with the Spec
Use automated testing tools like Schemathesis to validate that your API is compliant
with your specification. This can accelerate your acceptance testing and shorten your
feedback loops.
Finally, use your specification to generate, then publish client libraries for your API. I
have NEVER had to modify a client library generated by OpenAPI Generator, and
your users will love you for making it that much easier for them to consume your API.

Let me tell you a story . . .
11
Source:
https://www.redhat.com/en/about/videos/the-puckboard-story-transforming-us-armed-forces
About 2 years ago, we used this approach in a rather unique situation… Several
branches of the US Military needs a solution for scheduling training for their pilots
and air crew. Since the beginning, this scheduling was done by hand with qualifies
pilots and aircrew using a “puckboard”, a whiteboard dividing into grids and magnetic
“pucks” to indicate what, who, and where training would happen. This means that
many individuals who could be flying planes and managing cargo were in fact running
around collecting paperwork, training records, airspace allocations, and lots of other
information in order to do this scheduling. They had tried several times in the past to
hire contractors to build a system which could help them accomplish the task and all
of those initiatives had failed because only people truly immersed in the job could
comprehend what was involved. We took 6 uniformed service members . . . Airmen
and pilots . . . people with little or no skills in software development. We helped them
to prototype, design, validate, analyze, and synthesize a system. We then used this
contract-first approach to generate most of their implementation code. In the span of
about 2 months they produced a working MVP which they demonstrated to their
senior leadership in Washington D.C. The project was a HUGE success and is still
ongoing. In fact, the US Air Force has created a new division within their service
where uniformed service members develop software internally instead of outsourcing,
and are achieving higher quality, better fit, improved efficiency, and major cost
savings. This is just one of many examples I have seen first-hand over the last few
years.

Red Hat is the world’s leading provider of enterprise
open source software solutions. Award-winning
support, training, and consulting services make
Red Hat a trusted adviser to the Fortune 500.
Thank you
12
Try It Yourself
Learn More
https://bit.ly/rhcnad
bit.ly Red Hat Cloud Native App Dev RHCNAD

The Traditional Workflow
13
Project Planning
The business stakeholders spend time writing
up a project plan for a series of services and
potentially a user interface
Send To Developers
The various development teams attempt to
interpret the project plan and implement their
code so that they are compatible
Iterate And Integrate
The developer teams iteratively try to resolve
integration issues and spends lots of time
ensuring compatibility
This is a lot like traditional waterfall development of products, and as such it has lots
of bottleneck which prevent efficient progress. The project planning is a time
consuming process and often creates documents that are too vague and leave too
much room for interpretation. The developers try to consistently implement code
which is defined in the project plan, but differences of understanding and terminology
make it easy for separate teams to end up with incompatible implementations. This
results in lots of time and iterations required to resolve compatibility and integration
issues at a point very far along in the development process. Lots of re-work,
debugging, miscommunications, etc… Wouldn’t it be better if we could get faster
feedback?

14
● Editors
● Server Implementations
● Client Implementations
● Testing Tools
● Mocking Tools
OpenAPI Tools
There are many tools around OpenAPI which make it possible to do faster and more
asynchronous development so that teams, developers, customers, and partners can
develop clients and servers reliably.

OpenAPI Tools
15
Editors:
Source:
https://openapi.tools/
● APICurio (apicur.io)
● Swagger Editor (editor.swagger.io)
● VSCode
● IntelliJ
● Eclipse
There are a number of editors and tools which can be used to create/edit/validate an
OpenAPI specification. Red Hat actually has people working on Apicur.io, but
Swagger Editor and IDE plugins are also viable options.

OpenAPI Tools
16
Server Implementations:
Source:
● OpenAPI Generator (50+ Language/Framework combinations)
● NSwag (ASP.NET)
● Vert.x Web OpenAPI (Reactive)
● MicroTS (TypeScript)
● @smartrecruiters/openapi-first (JavaScript)
OpenAPI Generator can GENERATE code for a number of different languages (Java,
JavaScript, Go, Erlang, Elixir, Typescript, Ruby, Python, etc…) and frameworks (JAX-
RS, Spring, Express, Phoenix, etc…)
Vert.x toolkit includes the ability to generate RESTful endpoints and even generate
code for Service stubs
MicroTS generates a NodeJS/Express service using TypeScript
openapi-first also generates a NodeJS/Express server, but much of the boilerplate
code is generated on-the-fly at runtime and we just write business logic.

OpenAPI Tools
17
Client Implementations:
Source:
● OpenAPI Generator (65+ Language/Framework combinations)
● NSwag (CSharp/.NET)
● APIMATIC
● openapi-client-axios
OpenAPI Generator can GENERATE code for a number of different platforms (Java,
JavaScript, Go, Erlang, Elixir, Typescript, Ruby, Python, etc…) and frameworks (JAX-
RS, Spring, Express, Phoenix, etc…)
Vert.x toolkit includes the ability to generate client implementations in ANY of the
supported Vert.x languages (Java, JavaScript, Typescript, Clojure, Scala, Kotlin,
Groovy, etc..)
APIMatic is a SaaS solution for generating an SDK package in any number of
languages based on an OpenAPI Spec
openapi-client-axios can use an OpenAPI spec to create a fully async-enabled Axios
client for your JavaScript and Typescript applications

OpenAPI Tools
18
Testing Tools:
Source:
● Schemathesis
● Chai OpenAPI Response Validator
● hikaku
● Assertible
Schemathesis - My personal favorite right now. It’s a command-line tool which
reads your OpenAPI Spec and the base URL for your implementation. It then
uses property-based testing techniques to create tests to validate your
implementation. For example, in my simple Todo API it generates over 2000
tests for just 6 methods!!!
Chai OpenAPI Response Validator - Simple Chai support for asserting that
HTTP responses satisfy an OpenAPI spec.
hikaku - A library that tests if the implementation of a REST-API meets its
specification.
Assertible - Import an OpenAPI specification into Assertible to generate tests
that validate JSONSchema responses and status codes on every endpoint.

What’s The Workflow?
19 Source:
https://grpc.io/
https://github.com/
https://developers.google.com/protocol-buffers/
Using a tool like gRPC, write an API specification
FIRST
Write your specification in protoc format and
publish it to a public repository
Using a tool like protoc, create the API stubs for
both client and server applications. You can also
generate “mock” services and client SDK
libraries!
Another valid option for doing contract-first API development is to use gRPC:
gRPC is a modern open source high performance RPC framework that can run in
any environment. It can efficiently connect services in and across data centers with
pluggable support for load balancing, tracing, health checking and authentication. It is
also applicable in last mile of distributed computing to connect devices, mobile
applications and browsers to backend services.
gRPC specifications are written in a format called “protocol buffers” which is it’s own,
small, domain-specific language.
There are other solutions for contract-first, but OpenAPI and gRPC seem to be the
most widely adopted. Others include: RAML, RSDL, OData, APIBlueprint, I/O Docs,
Apache Avro, etc….

20
● Types
● Endpoints
● Verbs
● Parameters
● Security
● Extensions
Learning OpenAPI
Because of it’s massive amount of available tooling, we’re going to focus on OpenAPI
for now. There is significant documentation for gRPC available on-line if you should
choose to go that direction as well.

OpenAPI Basics
21
API Description:
---
openapi: 3.0.2
info:
title: Petstore
description: 'This is a sample Petstore API.'
termsOfService: http://redhat.com/terms/
contact:
email: open-innovation-labs@redhat.com
license:
name: Apache 2.0
url: http://apache.org/licenses/LICENSE-2.0
version: 1.0.0
---
openapi: 3.0.2
info:
title: Petstore
description: 'This is a sample Petstore API.'
termsOfService: http://redhat.com/terms/
contact:
email: open-innovation-labs@redhat.com
license:
name: Apache 2.0
url: http://apache.org/licenses/LICENSE-2.0
version: 1.0.0
externalDocs:
description: Find out more about OpenAPI
url: http://swagger.io
servers:
- url: https://petstore.swagger.io/v2
- url: http://petstore.swagger.io/v2
tags:
- name: pet
description: Everything about your Pets
externalDocs:
description: Find out more
externalDocs:
description: Find out more about OpenAPI
servers:
- url: https://petstore.swagger.io/v2
- url: http://petstore.swagger.io/v2
tags:
- name: pet
description: Everything about your Pets
externalDocs:
description: Find out more
Source:
OpenAPI documents are written in either YAML or JSON.
- They start with a declaration of which version of the OpenAPI specification we
are going to use to describe our API.
- The title and description are used when generating client SDKs from code
generators
- The “servers” section can be used to set up appropriate CORS and XSS
configurations
- The license lets your customers and partners know how they may re-use this
content.
Everything else here is informational and pretty much optional, though still good
practice for us to include.

OpenAPI Basics
22
Type Definitions:
components:
schemas:
Order:
type: object
required:
- id
- petId
properties:
id:
type: string
format: uuid
petId:
type: integer
format: int64
quantity:
type: integer
format: int32
components:
schemas:
Order:
type: object
required:
- id
- petId
properties:
id:
type: string
format: uuid
petId:
type: integer
format: int64
quantity:
type: integer
format: int32
shipDate:
type: string
format: date-time
status:
type: string
description: Order Status
enum:
- placed
- approved
- delivered
complete:
type: boolean
default: false
xml:
name: Order
shipDate:
type: string
format: date-time
status:
type: string
description: Order Status
enum:
- placed
- approved
- delivered
complete:
type: boolean
default: false
xml:
name: Order
Source:
In a section called “components” and a subsection called “schemas”, we can define
the data types which will be produced and consumed by our API. For example, here
we see an “Order” object defined. These schemas are defining the resources our API
will be producing/consuming.
- When defining a new type, you specify the type as “object”
- Next, you can define which fields are required to be valid
- Each field can be a primitive type or a reference to another object type, also
format
- If you wish to support XML, you can define what the top-level XML element
will be named
- Enumerated types are also supported

OpenAPI Basics
23
Endpoints:
/store/order:
post:
tags:
- store
summary: Place an order for a pet
operationId: placeOrder
requestBody:
description: order placed
content:
'*/*':
schema:
$ref: '#/components/schemas/Order'
required: true
/store/order:
post:
tags:
- store
requestBody:
content:
'*/*':
schema:
required: true
responses:
200:
description: successful operation
content:
application/xml:
schema:
$ref:
'#/components/schemas/Order'
application/json:
schema:
$ref:
400:
description: Invalid Order
content: {}
responses:
200:
content:
application/xml:
schema:
$ref:
application/json:
schema:
$ref:
400:
content: {}
Source:
Here we have defined a REST endpoint which handles a POST verb. The content of
the POST body is defined as accepting the “Order” type we showed in the previous
slide. We have also defined that our API consume and produces both JSON and
XML.
- The PATH for the endpoint
- The HTTP Verb for this operation
- The “operationId” is used by many code-generators to create method names
for both the server and client SDK implementations
- The content of the request is described either directly or using a reference to
a previously defined type
- Response codes and their associated bodies are defined either directly or
using a reference to a previously defined type

OpenAPI Basics
24
Parameters:
/store/order:
get:
summary: Retrieve all orders
operationId: getOrders
parameters:
- in: query
name: startDate
required: false
schema:
type: string
format: datetime
- in: query
name: endDate
required: false
schema:
type: string
format: datetime
/store/order:
get:
operationId: getOrders
parameters:
- in: query
name: startDate
required: false
schema:
type: string
format: datetime
- in: query
name: endDate
required: false
schema:
type: string
format: datetime
/store/order/{orderId}:
get:
operationId: getOrderById
parameters:
- in: path
name: orderId
required: true
schema:
type: string
format: uuid
/store/order/{orderId}:
get:
operationId: getOrderById
parameters:
- in: path
name: orderId
required: true
schema:
type: string
format: uuid
Source:
We can also specify the parameters which can be passed for various endpoints in
our API. Here we see query parameters and path parameters defined and we can
also see that some are required while others are not.

OpenAPI Basics
25
Security:
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
BearerAuth:
type: http
scheme: bearer
ApiKeyAuth:
type: apiKey
in: header
name: X-API-Key
OpenID:
type: openIdConnect
openIdConnectUrl: https://ex.io/oid-config
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
BearerAuth:
type: http
scheme: bearer
ApiKeyAuth:
type: apiKey
in: header
name: X-API-Key
OpenID:
type: openIdConnect
openIdConnectUrl: https://ex.io/oid-config
OAuth2:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://ex.io/oauth/auth
tokenUrl: https://ex.io/oauth/token
scopes:
read: Grants read access
write: Grants write access
admin: Grants admin access
OAuth2:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://ex.io/oauth/auth
tokenUrl: https://ex.io/oauth/token
scopes:
read: Grants read access
write: Grants write access
admin: Grants admin access
Source:
Here we have defined a REST endpoint which handles a POST verb. The content of
the POST body is defined as accepting the “Order” type we showed in the previous
slide. We have also defined that our API consume and produces both JSON and
XML.
- The PATH for the endpoint
- The HTTP Verb for this operation
- The “operationId” is used by many code-generators to create method names
for both the server and client SDK implementations
- The content of the request is described either directly or using a reference to
a previously defined type
- Response codes and their associated bodies are defined either directly or
using a reference to a previously defined type

OpenAPI Basics
26
Extensions:
/store/order:
post:
tags:
- store
x-vertx-event-bus:
address: com.myapp.store.order
requestBody:
content:
'*/*':
schema:
required: true
/store/order:
post:
tags:
- store
x-vertx-event-bus:
address: com.myapp.store.order
requestBody:
content:
'*/*':
schema:
required: true
responses:
200:
content:
application/xml:
schema:
$ref:
application/json:
schema:
$ref:
400:
content: {}
responses:
200:
content:
application/xml:
schema:
$ref:
application/json:
schema:
$ref:
400:
content: {}
Source:
The OpenAPI specification leaves room for extension, so if you want to implement
something specific to a toolkit/framework/platform; you can. For example, here we
see a field which start with “x-”, indicating it’s an extension to the OpenAPI
specification standard. This one is specific to writing applications using Vert.x and
allows us to tell Vert.x more information about our API in order to help it integrate with
the OpenAPI spec in a way which is toolkit specific. Sometimes you will see
extensions for database schema generation, or security support systems, etc… The
OpenAPI spec can be extended without writing any custom code, but you may like to
extend OpenAPI Generator so that it can generate more/better code for your
organization and even further reduce the amount of work required.

27
Optional subheading Lorem ipsum dolor sit
amet consectetuer adipiscing elit sed diam
Presentation title
should not exceed
three lines
Presenter’s Name
Title
OPTIONALSECTIONMARKERORTITLE

linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHat
28
open source software solutions. Award-winning support,
training, and consulting services make Red Hat a trusted
adviser to the Fortune 500.
Thank you

29
OPTIONAL SECTION MARKER OR TITLE
Optional supporting copy.
Lorem ipsum dolor sit
amet, consectetuer adipis
elit, sed diam nonummy
nibh euismod tincidunt ut
laoreet. magna aliquam.
Divider title
limit to two lines
QUICK TIP
Try right clicking on the photo and
using “Replace Image” to insert
your own photo. You are also
welcome to use this photo.

30
Divider title
limit to two lines
QUICK TIP

31
Divider title
limit to two lines
QUICK TIP

amet, consectetuer
adipisc elit sed dia nibh?
32

amet, consectetuer
adipisc elit sed dia nibh?
33

34
Lorem ipsum
dolor sit amet,
consectetuer
adipisc elit?

CORPORATE SLIDE TEMPLATES
35
This section
includes:Agenda slide templates
Content slide templates
Quote slide templates

What we’ll be
discussing today
AGENDA
36 Source:
Insert source data here
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic

AGENDA
37 Source:
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
Topic
What we’ll be
discussing today

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam nonummy nibh euismod tincidunt ut laoreet
38 Source:
QUICK TIP
Try right clicking on the photo and using
“Replace Image” to insert your own photo.
You are also welcome to use this photo.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim
veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea
commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit.

39 Source:
Body headline
Lorem ipsum dolor sit amet, consectet adipiscing elit sed dia.
Body headline
Body headline
Body headline
QUICK TIP
Try right clicking on the icon and using
“Replace Image” to insert your own icons.

40 Source:
Body headline
Lorem ipsum dolor sit amet, consectetuer
adipiscing elit, sed diam nonummy nibh mod
tincidunt ut laoreet dolore.
Body headline
Body headline
QUICK TIP
Try right clicking on
the photo and using
“Replace Image” to
insert your own photo.
You are also welcome
to use this photo.

41 Source:
Body headline
Body headline
Body headline
QUICK TIP

Lorem ipsum dolor sit amet,
consectetuer adipiscing elit,
sed diam nonummy nibh
euismod tincidunt ut laoreet
42 Source:
consectetuer adipiscing elit, sed
diam nonummy nibh euismod
tincidunt ut laoreet dolore magna
Body headline
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam
erat volutpat. Ut wisi enim ad minim veniam, quis nost.
Body headline
Body headline
QUICK TIP

43 Source:
Body headline
tincidunt ut laoreet dolore magna.
Body headline
Body headline
Body headline
QUICK TIP

44 Source:
Body headline
Lorem ipsum dolor sit amet, consectetuer adipiscin
elit, sed diam nonummy nibh euismod tincidunt ut
laoreet dolore magna aliquam erat volutpat. Ut wisi
enim ad minim veniam, quis nost.
Body headline
Body headline
Body headline
QUICK TIP

45 Source:
Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Duis id auctor dui. Ut neque
sem, convallis sit amet ultrices et, facilisis
vestibulum ligula. Donec euismod elementum
erat vitae fermentum. Mauris hendrerit
maximus bibendum.
“”
John Doe
CTO, Acme Unlimited
QUICK TIP
Using a photo with the large quote is optional.

46 Source:
Lorem ipsum dolor sit amet, consectetuer adipis
elit, sed diam nonummy nibh euismod tincidunt
ut laoreet dolore magna aliquam erat volutpat.
Ut wisi enim ad minim veniam, quis nostrud
exerci tation ullam.
“”
John Doe
CTO, Acme Unlimited
Lorem ipsum dolor sit amet, consectetuer adipis
elit, sed diam nonummy nibh euismod tincidunt
ut laoreet dolore magna aliquam erat volutpat.
Ut wisi enim ad minim veniam, quis nostrud
“”
Jane Doe
CTO, Acme Unlimited

47 Source:
consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut
laoreet dolore magna aliquam erat
volutpat. Ut wisi enim ad minim veniam,
quis nostrud exerci tation.
John Doe
CTO, Acme Unlimited
“” Lorem ipsum dolor sit amet,
John Doe
CTO, Acme Unlimited
“” Lorem ipsum dolor sit amet,
John Doe
CTO, Acme Unlimited
“”

48
This section
includes:Data slide templates
Table slide templates
Timeline slide templates

49 Source:
adipiscing elit, sed diam nonummy nibh euismod
tincidunt ut laoreet dolore magna aliquam erat.
65%
tincidunt ut laoreet dolore magna aliquam erat.
82%

50 Source:
aliquam erat volutpat. Ut wisi enim
ad minim veniam, quis nostrud
Label
00%
Lorem ipsum
dolor sit amet
00%
Lorem ipsum
dolor sit amet
00%
Lorem ipsum
dolor sit amet
00%
Lorem ipsum
dolor sit amet
00%
Lorem ipsum
dolor sit amet
00%
Lorem ipsum
dolor sit amet

51 Source:
aliquam erat volutpat. Ut wisi enim
ad minim veniam, quis nostrud
Body headline
adipiscing elit, sed diam nonummy nibh
euismod tincidunt ut laoreet dolore.
Body headline
adipiscing elit, sed diam nonummy nibh
euismod tincidunt ut laoreet dolore.
00% 00%

52 Source:
Body headline
00% 00% 00%
Body headline
Body headline

53 Source:
dolore magna aliquam erat
volutpat. Wisi enim ad minim.
Body headline
Body headline
000 000

54 Source:
000Body headline
000Body headline
000Body headline

55 Source:
01 Title of chart
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
Lorem ipsum
dolor sit amet
Lorem ipsum
dolor sit amet
QUICK TIP
Use the “Width Scale” in the “Size & Position” pane of the format
options panel to adjust the percentage of the bar.

56 Source:
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
00% Lorem ipsum
Lorem ipsum
dolor sit amet
Lorem ipsum
dolor sit amet
01 Title of chart
QUICK TIP
Use the “Width Scale” in the “Size & Position” pane of the format
options panel to adjust the percentage of the bar.

57 Source:
amet, consectetuer
adipiscing elit, sed diam
nonummy nibh euismod
tincidunt ut laoreet
COLUMN HEADER
TWO LINES MAXIMUM
COLUMN HEADER
TWO LINES MAXIMUM
COLUMN HEADER
TWO LINES MAXIMUM
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
limited to two lines
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
01 Title of table

58 Source:
01 Title of table
COLUMN HEADER
TWO LINES MAXIMUM
COLUMN HEADER
TWO LINES MAXIMUM
COLUMN HEADER
TWO LINES MAXIMUM
COLUMN HEADER
TWO LINES MAXIMUM
COLUMN HEADER
TWO LINES MAXIMUM
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
Body cell should be
Body cell should be
ROW HEADER
TWO LINES MAXIMUM
Body cell should be
Body cell should be
Body cell should be
Body cell should be
Body cell should be

59 Source:
Body headline
diam nonummy nibh euismod.
20XX
Body headline
20XX
Body headline
20XX
Body headline
20XX
Body headline
20XX
Body headline
20XX

60 Source:
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sedie
diam nonummy nibh euismod tincidunt ut laoreet dolore magna
aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud
exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea
Heading
QUICK TIP

61 Source:
Lorem ipsum dolor sit amet, consectet adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolor aliquam.
Heading
Heading
Heading
20XX
20XX
QUICK TIP
Try right clicking on
the photo and using
“Replace Image” to
insert your own photo.
You are also welcome
to use this photo.

62 Source:
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sedie
diam nonummy nibh euismod tincidunt ut laoreet dolore magna
aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud
exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea
Heading
QUICK TIP

Many people experience our brand by seeing
one of the thousands of presentations
Red Hatters deliver each year.
From Summit keynotes to conference-room sales meetings, we want our public face
to be coherent and recognizable. Our content must be meaningful and relevant to
our audiences. Our stories should be told in a clear, compelling way.
64
HOW TO BUILD AN EFFECTIVE PRESENTATION
https://pnt.redhat.com/pnt/p-611879/
GETTING STARTED WITH GOOGLE SLIDES
https://gsuite.google.com/learning-center/products/slides/get-started/#!/

Please use the Overpass font for
your presentation.
The Red Hat Display and Text fonts will be available in Google Slides
soon. We will update the template when it is available.
65

66
This section
includes:Title slide templates
Closing slide templates
Divider slide templates

linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHat
open source software solutions. Award-winning
support, training, and consulting services make
Red Hat a trusted adviser to the Fortune 500.
Thank you
67

Optional subheading
Presentation title should not
exceed two lines
Presenter’s Name
Title
Presenter’s Name
Title
68
QUICK TIP
Right click on the logo and using “Replace Image”
insert the product logo of your choice. Simply
delete if no product logo is needed.

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Recently uploaded

Recently uploaded (20)