Implementing API-led Cloud-native apps on OCI

© OPITZ CONSULTING 2020
¢¢¢ Digitale Service Manufaktur
Sven Bernhardt, Chief Architect / Integration
Evangelist
Implementing API-led
Cloud-native apps on OCI

© OPITZ CONSULTING 2020 Implementing API-led Cloud-native apps on OCI
That’s me
Sven Bernhardt
Cloud-Native enthusiast, API & integration geek. Always curious how new
technologies and concepts can help to make things more valuable and
efficient.
Proud father of a son, passionate football/soccer fan and player. Loves
listening to good hand-made music (Heavy Metal).
¢ Chief Architect / Integration Evangelist
@OPITZ CONSULTING Deutschland GmbH
¢ Oracle ACE Director
@sbernhardt
https://svenbernhardt.wordpress.com/
Seite 2

© OPITZ CONSULTING 2020 Seite 3
Agenda
1
2
3
4
5
Cloud-Native apps development
API-led architecture
API-driven development approach
Cloud-native apps in OCI
Summary
Implementing API-led Cloud-native apps on OCI

Cloud-Native apps development
1

© OPITZ CONSULTING 2020 Implementing API-led Cloud-native apps on OCI Seite 5
Why should I care about Cloud-Native development?
¢ Cloud is a competitive advantage (if used the right way)
¢ Increased speed / idea-to-market
¢ Increased scalability
¢ Increased flexibility
¢ Lower total cost of ownership (CAPEX à OPEX)

Characteristics of Cloud-Native applications
CNCF Definition of Cloud-Native:
Cloud native technologies empower organizations
to build and run scalable applications in
modern, dynamic environments such as public,
private, and hybrid clouds. Containers, service
meshes, microservices, immutable
infrastructure, and declarative APIs exemplify
this approach.
These techniques enable loosely coupled
systems that are resilient, manageable, and
observable. Combined with robust automation,
they allow engineers to make high-impact
changes frequently and predictably with
minimal toil.
Source: https://github.com/cncf/toc/blob/master/DEFINITION.md

Cloud-Native is an approach to build and run
applications that fully leverage the advantages of Cloud
Data
Single
Deployment
Unit
Traditional app development approach Cloud-native app development approach
UI
Logic
Data Access
UI
Logic
API
Data
UI
Logic
API
Data
Single
Deployment
Unit
Single
Deployment
Unit

API-led architecture
2

API-led architectures enables access to business
capabilities in a secure, comprehensible way
¢ Provides a standard-based interface for accessing the functionality
¢ Decouples Consumer and Provider
¢ Implements cross-cutting concerns, declared as policies
¢ AuthN/AuthZ
¢ Throttling/Rate Limit
¢ Routing
¢ Caching
¢ …
¢ Policy enforcement done by a specific runtime component
µService
API
API Exposure

Focus on API Consumers
¢ Main goal: Build consistent and easy-to-
use APIs!
¢ Describes how consumers can use a business
capability
¢ Support of different types of consumers (i.a.
introduce Single Purpose APIs)
¢ Development approach needed to
support collaboration:
¢ Decoupled development
¢ Quick feedback cycles
¢ API Mocking
Data
µService
µFrontend
API
API Exposure

API design-first approach
Feedback
Feedback
Intuitive, consistent API design is
key for API acceptance!
IMPORTANT

API Gateway
¢ Single entry point for clients to access Services
¢ No matter the implementation technology
¢ No matter the deployment model (Monolithic or µService)
¢ Provides a consistent governance model
¢ Decouples Client and Service implementation
¢ Is deployed separately in its own instance
¢ Deployment models:
¢ Bundled data and control plane
¢ Independent data and control plane
Source: https://tinyurl.com/yxbds3cd
Seite 12

API Gateway architecture considerations
¢ Implemented based on Cloud-native
principles
¢ API Design first
¢ Supports DevOps (CI / CD)
¢ Runs on every infrastructure (Containers,
VMs, etc.)
¢ Support for different types of APIs (REST,
GraphQL, gRPC)
¢ Hybrid architecture
¢ Cenrtralized Control plane (Management)
¢ Distributed Data planes (Workers)
Source: https://tinyurl.com/y67tlr77
Seite 13

API as prodcut and Service connectivity
¢ API as products
¢ API products needs to be accessible from outside and inside
¢ API Gateway as an abstraction layer
¢ Capabilities to cover: AuthN/Z, Rate limiting, Monetization, etc.
¢ Service Connectivity
¢ Enforce networking policies to connect, secure, encrypt, protect and observe
communication
¢ Client to API Gateway
¢ API Gateway to upstream service
¢ Capabilities to cover: Security (mTLS), Observability, Load balancing, Routing, Versioning
Seite 14

API Gateway is an important part to establish full
lifecycle API Management
API life cycle as proposed by Luis Weir (@luisw19)
in his book „Enterprise API Management“

API-driven development approach
3

Toolchain that supports development of API-driven
Cloud-native apps
Design Try
Create/
Configure
Deploy/
Run
Observe
Feedback
Mock
OCI API
Gateway
OCI
Container
Registry
OCI Logging
Oracle Developer
Cloud Service
OCI Container Pipelines
OCI Monitoring

Consistently design and mock your API Specs
¢ Supports API first design approach
¢ Collaboration through Github integration
¢ Ensures consistent API Design
¢ Support for API Blueprint and Open API 3.x
¢ Provide an API mock very early and without lots of effort
¢ Without coding and deployment
¢ Easily adjustable in case of feedback and respective changes

Create and configure the API
¢ Scaffold Client/Server code, e.g by generating Code based on the IDL
¢ Create APIs metadata and documentation (API page)
¢ Define API version
¢ Create API policies
¢ AuthN/AuthZ
¢ Throttling/Rate limit
¢ Key validation
¢ etc.

Automation is key for efficient app delivery
¢ Automate as much as as possible (Build, test, deployment, infrastructure)
¢ Define a consistent Build/Deployment process
¢ Make use of respective automation tools like Oracle Developer Cloud
Service or OCI Container Pipelines
Build &
Packag
e
QA Deploy Rollback
3 4 5 6
1) Checkout Sourcecode
2) Inspect Code and it‘s dependencies
3) Compile, package the Code and publish into an
Artefact repository
4) Quality assurance by conducting tests (Interface,
Functional, Performance, etc.)
5) Deploy to target environment (e.g. Production)
6) Rollback a previous deployment in case of issues with
certain components
Pull Inspect
1 2

Testing on different levels is key to ensure efficient and
consistent software delivery

Torch the light - See what‘s going on
¢ Observability is key in modern, distributed IT system landscapes
¢ Important to identify potential issues or bottlenecks
¢ Absolutely necessary to ensure SLA conformity
¢ Try to get as much insights as possible by externalizing as much
information as possible
¢ Different levels to track:
¢ API monitoring
¢ Service monitoring
¢ End-to-end monitoring
¢ Log analytics
¢ Application Performance monitoring
¢ Distributed Tracing

Cloud-native apps in OCI
4

Helidon – Set of Java libraries for developing Cloud-
native apps
¢ Open Source
¢ Hosted on Github (https://github.com/oracle/helidon)
¢ Support via Slack (https://helidon.slack.com)
¢ Apache 2.0 license
¢ Supported active project
¢ Innovative
¢ 2 different major versions (1.4.7, 2.1.0)
¢ Supports standards
¢ Microprofile 3.3

µService frameworks landscape
Dropwizard

Core differences Helidon SE and Helidon MP
¢ Microframework
¢ Tiny Footprint
¢ Functional style
¢ Reactive
¢ Simple & transparent
¢ GraalVM Native Image
¢ Microprofile 3.3 conform
¢ Small footprint
¢ Declarative style
¢ Dependency Injection
¢ Java EE specs: CDI, JAX-RS, JSON-
P/B

Helidon architecture
Netty
Helidon SE
WebServer Config Security
Helidon MP
CDI JAX-RS JSON- P/B
Extension

OCI Cloud-native services that provide a consistent and
solid runtime environment

Demo case
¢ API has been designed using
Apiary
¢ Backend service is implemented
using Helidon
¢ Contract testing is done using
Dredd
¢ Backend service container has
been uploaded to OCIR and
deployed to OKE
¢ Backend Service is exposed with
OCI API Gateway
Consumer
Backend
Svc
API Exposure
K8s Ingress

Oracle Container Engine for Kubernetes (OKE)
Based on IaaS Oracle Compute
Cloud Service
Worker Nodes: VM
Master Node:
•Managed and maintained by Oracle
•Not visible for the end user
•Master nodes are free of charge
Auto-scaling capabilities using
Worker-Node Pools
Can be provisioned using
OCI Cloud Console
OCI Cloud Shell
OCI CLI
Terraform (OCI Resource Manager)
Seite 30

OCI Container Registry
¢ Open standards-based, Oracle-managed Docker registry service for
securely storing and sharing container images (Docker v2 compliant)
¢ Data protection through integration with OCI object storage
¢ Automatic clean up old docker images (Retention policies)
¢ Integrates with different OCI services and 3rd party DevOps and dev
tools (Jenkins, Gitlab)
¢ Container Engine for Kubernetes (OKE)
¢ Identity and Access Management (IAM)
¢ Visual Builder Studio
¢ Docker containers can be pushed/pulled by Docker CLI and API

OCI API Gateway
¢ Fully-managed API Gateway
¢ Enables to publish API endpoints that are accessible
¢ Within the Cloud network only
¢ From the public internet
¢ Currently only REST APIs are supported
¢ Exposed API endpoints support: API validation, Request/Reponse
transformation, CORS, AuthN/Z, Rate limiting
¢ Can be provisioned using:
¢ OCI Cloud Console
¢ OCI Cloud Shell
¢ OCI CLI
¢ Terraform (OCI Ressource Manager)
Seite 32

Summary
5

Key takeaways
¢ Apps should be built in a Cloud-native fashion
¢ Containers, DevOps and APIs are basic building blocks
¢ API design-first is important for consistent, intuitive API design
¢ Consistent, intuitive APIs are essential for API acceptance
¢ An API that is not used, is useless
¢ API design is as important as for Cloud-native apps, as UI design (UX) is for User interfaces
¢ APIs help to further transparency with respect to Service usage
¢ Who is using a specific µService?
¢ How many requests are sent to this specific µService resp. to certain resources?

OCI as platform for Cloud-native apps
¢ Provides a broad spectrum of services to
support Cloud-native app development and
operations
¢ OCI services are build around broadly-used
frameworks, tools and specifications
¢ Open API
¢ Kubernetes
¢ MicroProfile
¢ Fn Project
¢ FluentD
¢ Offering is still growing, gets broader and
more mature

Links & Resources
¢ Apiary: https://apiary.io
¢ API conversions: https://apimatic.io
¢ Dredd HTTP testing: http://dredd.readthedocs.io/en/latest/
¢ Oracle Container Engine for Kubernetes documentation
¢ OCI API Gateway documentation

Q & A

¢¢¢ Digitale Service Manufaktur
@OC_WIRE
OPITZCONSULTING
opitzconsulting
opitz-consulting-bcb8-1009116
WWW.OPITZ-CONSULTING.COM
Thanks for your attention!
Sven Bernhardt
Chief Architect / Integration Evangelist | Oracle ACE Director
OPITZ CONSULTING Deutschland GmbH
Kirchstrasse 6, 51647 Gummersbach, Germany
Phone: +49 172 2193529
Mail: sven.bernhardt@opitz-consulting.com
@sbernhardt
https://svenbernhardt.wordpress.com
Seite 38

Implementing API-led Cloud-native apps on OCI

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Implementing API-led Cloud-native apps on OCI

Similaire à Implementing API-led Cloud-native apps on OCI (20)

Plus de Sven Bernhardt

Plus de Sven Bernhardt (10)

Dernier

Dernier (20)

Implementing API-led Cloud-native apps on OCI