From SAP Inside Track Copenhagen 17 Nov 2018

1. KICKSTART YOUR
MICROSERVICE
LANDSCAPE
SAP Inside Track Copenhagen
By Søren Amdi Bach
Principal Application Architect
KMD SCE/SAP Central Design
Authority
17 Nov. 2018
Who is Søren:
Principal Application Architect at KMD A/S
Professional, curious and enthusiastic technology nerd with a sense of
business and social skills
Some SAP technology words from the recent years:
S/4HANA (Public Cloud, On Premise, Conversion), SAP Cloud Platform,
SAP Leonardo, SAP Solution Manager, HANA Database, Security,
HANA/ABAP: Development, governance, quality, DevOps etc.
Various architect roles the last + 15 years, mainly SAP for the last 12-
13 years
Origin in development/technology: SAP, Microsoft, IBM MVS, Open
Source and Unix

2. ▪ Defined by Gartner
▪ Ref.: https://www.gartner.com/it-glossary/bimodal
▪ Interpreted by SAP
BI-MODAL IT
SAP S/4HANA
SAP Business Suite
SAP Leonardo
SAP Cloud Platform

3. 3
▪ An answer to:
▪ Requirements of public cloud applications (mode 2)
▪ The world of services with business models around
exposing and consuming services (service economy)
▪ Industry 4.0 (Interaction of Cyper Physical Systems
forming cross enterprise value chains)
▪ Boundless Scalability:
millions of users, thousands of servers, petabytes
of data, globally distributed
▪ High Availability:
zero downtime deployments, seamless failover
▪ Fast Innovation:
develop, build, and ship in short cycles, even daily
MICROSERVICE ARCHITECTURE AS AN ARCHITECTURE PATTERN IN MODE2
WHY?

4. ▪ Origin in Unix philosophy:
“Do one thing and do it well”
▪ The services are small - fine-grained to perform single functionality.
▪ The organization culture must embrace automation of testing and deployment. This eases the burden on
management and operations and allows for different development teams to work on independently
deployable units of code.
▪ The culture and design principles must embrace failure and faults, similar to anti-fragile systems.
▪ Each service is elastic, resilient, composable, minimal, and complete.
▪ Martin Fowler definition:
“Microservice architecture is an approach to developing a single application as a suite of small
services, each running in its own process and communicating with lightweight mechanisms, often
an HTTP REST API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery.”
MICROSERVICE CONCEPT/PHILOSOPHY– IN A NUTSHELL

5. ▪ A traditional SAP system are one large logical system with a single (SQL) DB
▪ Transactional consistency for all data is guaranteed
▪ Big, infrequent releases with larger upgrade project seen as high risk
▪ Hard to apply cloud requirements
▪ Monolith must be built, tested, deployed and scaled as a whole
▪ Vertical scaling is limited (requires more expensive servers) – cost is non-linear
▪ System is often sparse utilized designed for peak-time
▪ High availability setup requires almost double the infrastructure
CHARACTERISTICS OF CLASSICAL SAP SYSTEM VS. CLOUD REQUIERMENTS
5

6. 6
CONNECTION BETWEEN CLOUD ENVIRONMENT AND ON PREMISE LANDSCAPE
USING CLOUD CONNECTOR
API management scenarios
On-premise/LOB (SaaS)
side by side extension
scenarios
!

7. THE NETWORK OF APPLICATIONS (MICROSERVICES) CONNECTED TO YOUR
ON-PREMIS SYSTEMS IN YOUR DATACENTER
7
DataCenter
Persistence
Service
Container
Microservice
Container
Microservice
DataCenter
Persistence
Service
Container
Microservice
Container
Microservice
Your On-Premis DataCenter
Cloud Connector
S/4HANA
Business
Suite
SAP
Gateway
Non-SAP with
Rest/Odata interface

8. 8
PURSUED ASPECTS OF A MICROSERVICE
Elastic
Be able to
scale up or
down
independently
of other
services in the
same
application
Resilient
Fail without
impacting
other services
in the same
application
Composable
Offer an
interface that
is uniform and
is designed to
support
service
composition
Minimal
Only contain
highly
cohesive
entities.
The content
should be
focused on the
same tasks
Complete
Offer complete
functionality
covering the
task with a
minimal
dependencies
to other
services

9. ▪ Not the nature of on-premise – dedicated Hardware
▪ Vertical scaling is limited (requires more expensive servers) – cost is non-linear
▪ Possible Solution Components
▪ The expensive solution: Buy enough hardware for your on-premise
(Dream scenario of the HW vendors)
▪ API Management – to protect against burst loads (the throttling concept)
▪ When the microservice “goes viral”: Be ready to redesign to decouple the synonymous
dependency between scalable “Container” and on-premise.
Consider asynchronous data replication framework between on on-premise and scalable cloud
persistence
NOT THAT EASY
- MIGHT GET EXPENSIVE WHEN YOU TRY
9

10. NOT OUT OF THE BOX
- REQUIRES SOME WRAPPING TO ACHIEVE
10
▪ Key drivers for resilience
▪ Respond to service client with in acceptable time
▪ Protect the on-premise system against burst load (limited resources)
▪ In case of error
1. Ensure transactional consistency – don’t leave any partial maintained Business Objects in
the on-premise system.
2. Ensure releasing all technical resources – don’t rely on the technical time out or garbage
collection, this will lock to many resources while systems is squeezed
▪ Possible Solution Components
▪ API Management – to protect against burst loads (throttling)
▪ Hystrix or similar - to ensure response time, fall-back and resources for error handling
▪ Cloud integration or workflow to build smooth and reliable orchestration

11. THIS DEPENDS –
WHAT ARE YOU REUSING
11
▪ Might be out of the box – the on-premise services matches the size of a
microservice
▪ More on-premise services required to construct the functionality and data
required to be exposed as a microservice
▪ Required information distributed across more
▪ Transactional Scope
▪ Possible Solution Components
▪ Cloud integration or workflow to build smooth and reliable orchestration of the on-premise
services
▪ Note: Prepare for redesigning the orchestration when the usage pattern of the
microservice doesn’t fit the synchronous communication to on-premise

12. 12
Value of doing it
▪ Fast, Easy and relative cheep to get started
▪ Opens the possibility to build functional “mock-
up” microservice by reusing on-premise
functionality in a synchronous setup.
▪ If business potential is limited and the amount of
potential users is limited (no need for elasticity)
Early test on business Viability on cheaper
functional mock-up
▪ Start small and incorporate customer/market
feedback before designing the real microservice
architecture
Prepare for investment if success
▪ You know the business viability before the larger
investment
▪ You might be left technical behind if the service
consumption speeds up heavily
The Operational Cost Driver
▪ The distribution and amount of usage of the
microservice
▪ The anticipation on the user base growth and how
to control.
The Devil in the detail
▪ Is the scenario at all covered by your On-premise
license or will the cost of this follow the peak
consumption?
CONSIDERATIONS – DOES THIS AT ALL MAKE SENSE

13. 13
▪ Open SAP Courses
▪ Cloud-Native Development with SAP Cloud Platform
https://open.sap.com/courses/cp5
▪ Cloud-Native Operations with SAP Cloud Platform
https://open.sap.com/courses/cp4
▪ Smart Service Welt – Data and Platform-Based
Business Models
https://open.sap.com/courses/ssw1-tl
▪ SAP Cloud Platform API Management
https://open.sap.com/courses/cp8
▪ SAP Cloud Platform Version Control with Git
https://open.sap.com/courses/git1
▪ Writing Testable Code for ABAP
https://open.sap.com/courses/wtc1
▪ From SAP TechEd 2018
▪ OPP400 –Micro services in an Agile Environnent
▪ OPP361 – Resilient Micro services and APIs in Practices
▪ Other ressources
▪ Microservices - a definition of this new architectural
term
https://martinfowler.com/articles/microservices.html
▪ Bounded Context
https://martinfowler.com/bliki/BoundedContext.html
▪ On the Definition of Microservice Bad Smells
https://www.computer.org/csdl/magazine/so/2018/03/
mso2018030056/13rRUx0getv
▪ Pattern: Microservice Architecture
https://microservices.io/patterns/microservices.html
▪ The Twelve-Factor App https://12factor.net/
▪ Microservices: Decomposing Applications for
Deployability and Scalability
https://www.infoq.com/articles/microservices-intro
▪ Microservices in a Nutshell. Pros and Cons.
https://blog.philipphauer.de/microservices-nutshell-
pros-cons/
WANT TO KNOW MORE ON THE TECHNICAL POSSIBILITIES?