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 and API design-first
Cloud-native development approach
OCI Cloud-native Services
Summary
Implementing API-led Cloud-native apps on OCI

¢ JSF (Java Server Faces) or Spring MVC:
¢ Java Programming Model for the web
¢ Java for implementing business logic
¢ No JavaScript, SQL, … Everything abstracted away
¢ RDBMS (like Oracle database)
¢ Runtime: JEE/Servlet-Container (like Weblogic / Tomcat)
The good old times
Implementing API-led Cloud-native apps on OCI Seite 4

¢ One Language
¢ One Development Stack
¢ Production is an afterthought
¢ Is that really all?
¢ Not quite, because sometimes we had things like Maven, Git or
Jenkins CI
¢ But that’s it; Really!
The world was easy, wasn’t it?
Implementing API-led Cloud-native apps on OCI Seite 5

Cloud-Native apps development
1

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

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 Source: https://pivotal.io/cloud-native

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
Isolated Process (e.g. JVM)

Cloud-native characteristics
API design-first
• Define the contract before implementing
• Supports multi-team development
• Not only REST, but also Events, GraphQL,
GRPC, …
Dependency Management
• Rigorous management of anything to
develop and run your application
• Security checks per default
• Libraries, Container Images, Tools, …
Elasticity
• Think about quickly scaling up and gracefully
scaling down
• Efficient resource usage
Environment Parity
• Same procedures on every environment
• Same people
• Every commit is a deployment candidate

Environment Parity
Every commit is a deployment candidate
•No more snapshot versions!
•Every commit has a defined (semver) version:
1.2.681+sha.036b602
Use the same container images locally for your
development environment, CI process and
production
•Build once, run anywhere!
•docker and docker-compose are important skills for every
developer, DevOps Engineer and sysadmin
Understand the needs of production
(you may suffer yourself)
•When creating images or thinking about configuration,
logging etc think about constraints and environments the
application is running when not on your laptop
•Reuse frameworks that help, like spring-actuator (don't
reinvent the wheel!)

API-led architecture and API design-
first
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 life cycle
Design
Mock
Try
Create/configureDeploy
Promote,
deprecate, retire
Observe
API ideation &
planning
API life cycle as proposed by Luis Weir (@luisw19)
in his book „Enterprise API Management“

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 17

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 18

Cloud-native development approach
3

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

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
Commit Push
Code Style
Check
Compile Unit Test Integration Test
Manual
Acceptance
Test
Load Test /
Performance
Test
Security Test
Deploy +
Release
Automate as much as as
possible (Build, test,
deployment, infrastructure)
Define a consistent
Build/Deployment process
Make use of respective
automation tools like
Spinnaker, Tekton or Argo
CD
Include Security in your
build pipeline (DevSecOps)

Testing on different levels is key to ensure efficient and
consistent software delivery
¢ Writing tests to gain
confidence
¢ Static code analysis
(improve Code quality)
¢ Unit test isolated parts
of the app
¢ Test units in integration
¢ Testing E2E workflow
Cost
Speed
Confidence
Source: https://tinyurl.com/y6k533or

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

OCI Cloud-native Services
3

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

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 28

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 30

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

Demo: Cloud-naitve development in Action
1
2
3
4
5

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?

With respect to Cloud-native development, you’re spoilt
for choice! https://landscape.cncf.io/

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

Links & Resources
¢ Example code: https://github.com/svenbernhardt/employee-service-
helidon-se
¢ Report: State of API Management, Postman
¢ Apiary: https://apiary.io
¢ API conversions: https://apimatic.io
¢ Dredd HTTP testing: http://dredd.readthedocs.io/en/latest/
¢ CNCF Cloud-native landscape: https://landscape.cncf.io/

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 42

Implementing API-led Cloud-native apps on OCI

Recommended

More Related Content

What's hot (20)

Similar to Implementing API-led Cloud-native apps on OCI (20)

More from Sven Bernhardt (17)

Recently uploaded (20)

Implementing API-led Cloud-native apps on OCI