Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Kickstart yourmicroservicelandscape

57 vues

Publié le

From SAP Inside Track Copenhagen 17 Nov 2018

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

  • Soyez le premier à aimer ceci

Kickstart yourmicroservicelandscape

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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?

×